From robin.cornelius at gmail.com Fri May 1 13:42:46 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri, 01 May 2009 21:42:46 +0100 Subject: [sldev] [PATCH] Fix viewer manifest when closed libs are not present Message-ID: <49FB5EC6.9080404@gmail.com> When building the viewer the LL way and llkdu or fmod are not present, 32 bit linux builds choke on the viewer_manifiest script exceptioning on the missing files. I've just attached a patch to http://jira.secondlife.com/browse/VWR-12533 to correctly handle the exceptions if the files are not present and print a warning. I know fmod is legacy on linux now and i know easy build will eventually make this obsolete. But looking for a nod for a commit to http-texture to fix another bug-bear of mine when building. 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/20090501/f272fea7/attachment.pgp From secret.argent at gmail.com Fri May 1 03:28:09 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 1 May 2009 05:28:09 -0500 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <9bb32d430904300612x1274bfa8y31a764f5c6009f53@mail.gmail.com> References: <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> <9bb32d430904300237w5db5ce6apcc67ef0141d408@mail.gmail.com> <9bb32d430904300601g37b4a386rc74099cb4c42b746@mail.gmail.com> <9bb32d430904300604i58b2d0f5l6eccfd1e4470210a@mail.gmail.com> <49F9A242.8040408@streamsense.net> <9bb32d430904300612x1274bfa8y31a764f5c6009f53@mail.gmail.com> Message-ID: On 2009-04-30, at 08:12, Ambrosia wrote: > On a note, with the FLOSS exception not including the licenses for > Quicktime, FMOD and Vivox..I sense a massive oversight on part of LL > here. This quite frankly renders third party viewers useless for most > residents. Those who don't care about any Backgrounds and want their > voice and streaming videos. Most residents don't use Voice or watch videos. From sllists at boroon.dasgupta.ch Fri May 1 06:26:33 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 01 May 2009 15:26:33 +0200 Subject: [sldev] [IDEA][META] hg branch for trivial changes Message-ID: <49FAF889.2040200@boroon.dasgupta.ch> Hi all I plan to clone http://bitbucket.org/lindenlab/http-texture/ to have a place to collect trivial changes to the viewer code base, such as fixing typos or indentation. Before I do so, I'd like to hear your opinion about it. Past and current situation If I remember correctly, Linden Lab once discouraged us from sending them indentation-only patches, because the overhead to review and import them was too much in relation to the benefit of such changes. Instead we should clean up code while working on the specific parts for bigger bugs of features. This is quite some while ago, so I don't know if that's still the current recommendation. However, this neglects that working on such small and trivial changes gives new and unexperienced (potential) contributors the opportunity to get to know the source while not having to fear to break something. Also, while the individual trivial changes are probably rather unimportant, together they should greatly improve the experience of both, developers working on "real" features and bug fixes, as well as the casual reader of the code who tries to figure out how something works. Proposal So I'll keep a public clone of LL's most active public hg branch (currently http-texture) where such trivial changes will be collected. If you have such a change (or several), send me a pull request (preferred) or a patch. LL can then regularly pull from my clone and review several such changes in batch. To make it possible to do this in some fast-forward manner at LL's side, I'll review the changes I'll pull myself and filter them according to the following principles: * functional triviality, which means either o no change in behavior of the viewer (e.g. fixing indentation of a non-python source file) or o change towards the expected/wanted behavior when it is relatively save to assume nobody is relying on the current unexpected/faulty behavior (e.g. fix a typo in debug output) * code triviality o the functional triviality should be trivial to see (i.e. major code refactoring doesn't qualify for this branch) * creative triviality o LL should be able to safely apply the changes, even with no contribution agreement from the contributing developer on file. Of course, because I'm not LL's legal department, I'll have to guess about the last point, but I think knowing that I already have checked and decided about that issue for the changes in my clone will still save LL some time when reviewing those changes. Rationale I'll keep this in FAQ/Q&A style, only that I've invented all the questions myself: Aren't these rules too strict? I recognize they're rather strict, but they're probably necessary to guarantee the changes can be imported by LL as quickly as possible. Also, I think there are very much potential changes that match these strict restrictions, so having a branch for them might be worthwhile. Why no major refactoring? That's important, too. Yes, it is. But it's harder to review and will in most cases warrant its own branch. Remember, with hg, branching is almost free and merging, while still work, is much easier. Why not just collect patches for such changes in a PJIRA issue, and have LL import that? While creating a patch and creating a hg changeset is about the same amount of work, managing patches, applying them for testing and combining them is very tedious. Also, we would have to either keep one issue constantly open or create a new one from time to time, which both makes triages more complicated which shouldn't be needed at all for the changes in question. How will your judgment save LL any time? They'd either have to trust you or review everything as accurately as they would otherwise. Of course, because my contributions up to now where rather marginal, LL doesn't have any reason to trust my judgment initially. I hope they'll start pulling from my clone just for the convenience of having all these changes available at a single location. I'll give my best to prove myself worthy of being trusted, so they can pull more and more "blindly" after some time. You'll personally review everything? That doesn't scale! Once the work gets to much for me alone (or even before), I can invite other contributers as reviewers if I trust them by giving them commit/push permissions to the clone. If even that doesn't scale anymore (which won't be any time soon), we can easily switch to cascaded review as used by the linux kernel where everyone pulls from repositories they trust until stuff ends up in the 'central' one. Open questions What should we name that clone/branch? "slviewer-cleanup" doesn't quite fit, because there will be some changes qualifying for this branch which aren't pure cleanup. "slviewer-trivial" sounds like a trivial implementation of an SL viewer, which this won't be, as it'll build on the current code base. Until the move to hg is completed, will LL keep the http-texture branches in the SVN and hg repositories in sync enough? Would this branch and process actually be useful for LL and/or the OSS community? Please let me know what you think! cheers Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090501/cf6729dc/attachment.htm From soft at lindenlab.com Fri May 1 06:46:57 2009 From: soft at lindenlab.com (Soft) Date: Fri, 1 May 2009 08:46:57 -0500 Subject: [sldev] [IDEA][META] hg branch for trivial changes In-Reply-To: <49FAF889.2040200@boroon.dasgupta.ch> References: <49FAF889.2040200@boroon.dasgupta.ch> Message-ID: On Fri, May 1, 2009 at 8:26 AM, Boroondas Gupte wrote: > Hi all > > I plan to clone http://bitbucket.org/lindenlab/http-texture/ to have a place > to collect trivial changes to the viewer code base, such as fixing typos or > indentation. Before I do so, I'd like to hear your opinion about it. > > Past and current situation > > If I remember correctly, Linden Lab once discouraged us from sending them > indentation-only patches, because the overhead to review and import them was > too much in relation to the benefit of such changes. Instead we should clean > up code while working on the specific parts for bigger bugs of features. > This is quite some while ago, so I don't know if that's still the current > recommendation. The problem with indentation patches isn't review, it's merging. If 200 lines in one file are indented, they all show up as changed. What happens when that's merged with a branch without the indentation change, but where one line in that soup of 200 was changed? It's very likely that the change with a code effect will get lost without a very, very careful eye. It's also going to slow down the merge, which extends our critical path. LL's own future move to mercurial or better merge tools may change that. The remaining question would then be review time. Right now, a bunch of formatting changes wouldn't make it back to the tree, though. From q at lindenlab.com Fri May 1 07:58:11 2009 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Fri, 1 May 2009 10:58:11 -0400 Subject: [sldev] Open Source Meeting, 2PM PDT, Hippotropolis In-Reply-To: <49FA398A.5090105@watson.ibm.com> References: <3B7F46F8-2F96-49B9-B62F-879D3BBD3B34@lindenlab.com> <49F9CA9A.2000103@watson.ibm.com> <49FA398A.5090105@watson.ibm.com> Message-ID: Thanks for the outline, Mike. I've created a version of it here from comments Merov has made plus a few of my own: https://wiki.secondlife.com/wiki/SLDev_Open_Source_Viewer I'd encourage Lindens -- especially Merov and Philip -- to expand on it. Q On Apr 30, 2009, at 7:51 PM, Mike Monkowski wrote: > As I warned :-) at the meeting today, I'm making up documentation > for this new Open Source Viewer process. You can see the work in > progress at http://wiki.secondlife.com/wiki/User:Mm_Alder/SLDev_Open_Source_Viewer > Feel free to edit whatever you like. I'm only doing this because > no one else would. :-) > > Mike > > Mike Monkowski wrote: >> I added: >>> # Can we get better documentation on the open source viewer >>> project (aka http-texture)? Is there anyone other than me who >>> would be interested in open code reviews for this project? Mm >>> Alder 15:57, 30 April 2009 (UTC) >> Kent Quirk (Q Linden) wrote: >>> Please add items to the agenda if you wish: >>> >>> http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda >>> >>> I'll be hosting today. From sllists at boroon.dasgupta.ch Fri May 1 09:40:44 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 01 May 2009 18:40:44 +0200 Subject: [sldev] [META] indentation fixes/changes and merging (was: [IDEA][META] hg branch for trivial changes) In-Reply-To: References: <49FAF889.2040200@boroon.dasgupta.ch> Message-ID: <49FB260C.7010408@boroon.dasgupta.ch> Soft schrieb: > On Fri, May 1, 2009 at 8:26 AM, Boroondas Gupte > wrote: > >> If I remember correctly, Linden Lab once discouraged us from sending them >> indentation-only patches, because the overhead to review and import them was >> too much in relation to the benefit of such changes. Instead we should clean >> up code while working on the specific parts for bigger bugs of features. >> This is quite some while ago, so I don't know if that's still the current >> recommendation. >> > > The problem with indentation patches isn't review, it's merging. > > If 200 lines in one file are indented, they all show up as changed. > What happens when that's merged with a branch without the indentation > change, but where one line in that soup of 200 was changed? It's very > likely that the change with a code effect will get lost without a > very, very careful eye. Hmm ... indeed. Forgot about that one. :-( > It's also going to slow down the merge, which > extends our critical path. > > LL's own future move to mercurial or better merge tools may change > that. The remaining question would then be review time. Right now, a > bunch of formatting changes wouldn't make it back to the tree, though. > I fear hg (or any other modern SCM) won't help very much here, as their automatic merging is still line-based, so this will almost always trigger a merge conflict to be resolved manually. I wonder how other big projects handle this issue, as keeping false indentation in the code until the specific part of code is touched for another reason can't be the proper solution. Boroondas From soft at lindenlab.com Fri May 1 09:56:00 2009 From: soft at lindenlab.com (Soft) Date: Fri, 1 May 2009 11:56:00 -0500 Subject: [sldev] [META] indentation fixes/changes and merging (was: [IDEA][META]hg branch for trivial changes) In-Reply-To: <49FB260C.7010408@boroon.dasgupta.ch> References: <49FAF889.2040200@boroon.dasgupta.ch> <49FB260C.7010408@boroon.dasgupta.ch> Message-ID: On Fri, May 1, 2009 at 11:40 AM, Boroondas Gupte wrote: > Soft schrieb: >> On Fri, May 1, 2009 at 8:26 AM, Boroondas Gupte >> wrote: >> >>> If I remember correctly, Linden Lab once discouraged us from sending them >>> indentation-only patches, because the overhead to review and import them was >>> too much in relation to the benefit of such changes. Instead we should clean >>> up code while working on the specific parts for bigger bugs of features. >>> This is quite some while ago, so I don't know if that's still the current >>> recommendation. >>> >> >> The problem with indentation patches isn't review, it's merging. >> >> If 200 lines in one file are indented, they all show up as changed. >> What happens when that's merged with a branch without the indentation >> change, but where one line in that soup of 200 was changed? It's very >> likely that the change with a code effect will get lost without a >> very, very careful eye. > Hmm ... indeed. Forgot about that one. :-( >> It's also going to slow down the merge, which >> extends our critical path. >> >> LL's own future move to mercurial or better merge tools may change >> that. The remaining question would then be review time. Right now, a >> bunch of formatting changes wouldn't make it back to the tree, though. >> > I fear hg (or any other modern SCM) won't help very much here, as their > automatic merging is still line-based, so this will almost always > trigger a merge conflict to be resolved manually. I wonder how other big > projects handle this issue, as keeping false indentation in the code > until the specific part of code is touched for another reason can't be > the proper solution. Honestly, I think they handle it by not having branches spend so long diverged from trunk/. The chances of merge conflicts go up exponentially with the number of changes made independently. Better compartmentalization of the code would also help. It would become more likely that cleanup changes could be made in the branch where other development on that code is happening. The take-away I get from this is that cleanup is hard if the code is already poorly structured. So that underscores the importance of cleaning up code when touching the code for other purposes. Maybe this means the best way for you to go forward with your project would be to look for ways to link pools of janitorial work to other patch submissions touching the same code. From philip at lindenlab.com Fri May 1 11:02:21 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Fri, 01 May 2009 11:02:21 -0700 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com><49F77537.8010609@w atson.ibm.com><493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com><49F867E1.6040805@watson.ibm.com><784490.3996.qm@web59104.mail.re1.yahoo.com><49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> Message-ID: <49FB392D.3060004@lindenlab.com> Sorry gang that I've been away from the list for a few days, I sometimes get busy. We had a board meeting tuesday, etc. OK! This is clearly a tough issue with lots of appropriate debate. Good example of the kind of thing we'll need to feel our way into some sort of a process for. After reading the thread on this topic as closely as I've had time, here are my summary thoughts: * We need a clear and discoverable place in the UI where this feature can be enabled and disabled. Probably prefs. Can someone take on that design and coding? Advanced-> isn't the right home for this. We should do that work properly and well to complete this feature. * Can someone (Mike?) add a bit more detail on the jira task to defend/review that the CPU impact is strictly capped. For example, what is the LOD behavior if there are 100 avatars all talking at the same time. We have LOD tricks for various rendering aspects of the system, do they correctly carry through? Does the CPU load of the feature vary by GPU? I think we need this level of documentation. * As to the question of whether to default it on or off, clearly it is a complex issue. I'd say lets default it on, and make sure it is easy to find the way to turn it off. For some use cases it is very cool, lending immersion and cueing as to speaker. For other cases you will want it off. We are still at the point where the 'uncanny valley' nature of the feature can make it unnerving, and that problem is unlikely to be easily solved soon in realtime with low CPU load. As a final note, I'd say this is a good example of a tough topic where the right call is unclear and discussion and debate is appropriate. Also a good case of where if need be, I can just make a call and we move on and see what happens. Given that, why the rudeness I am seeing here? I don't see a need to be insulting to each other over this topic. Maybe I've missed some painful history here, but can't see how this is helping us move forward. I wouldn't work internally on projects at LL with colleagues that were overly rude, I don't see why it should be any different here! Philip Philippe Bossut (Merov Linden) wrote: > Hi, > > Thanks Moritz for the fair and clear summary of this issue. Putting in > my L$0.02, I'll add that we think it's fine to have this "turned on by > default" (which will only impact residents using voice chat as stated > in that thread) and that our BDFL already said so (may be not in > public though... Philip?). We already selected this VWR as one of the > community voted feature that we'll get in "http-texture" (aka the > "Second Life OSS" viewer). > > Since I'm at it, there is a wiki page that lists the bugs and features > we (collective "we", not just Lindens...) are working on for the next > and first release of this viewer. It is there: > https://wiki.secondlife.com/wiki/HTTP_Texture_Development#Pending_merge_queue_proposals > > I'll follow up on another thread on the state of that viewer so far in > a little while. > > Cheers, > - Merov > > > On Apr 29, 2009, at 3:42 PM, Moriz Gupte wrote: > >> To summarize and to clarify: >> I feel these are the points important to state >> >> 1. We are not discussing voice >> 2. Voice has always been optional >> 3. lipsync has negligible footprint (as Mike has patiently and >> repeatedly mentioned inspite of various reflex reactions) In my own >> experience, enabling or disabling lipsync has no effect on our fps >> and all our machines share the exactly the same settings/I have 3 >> generations of hardware to work with and no impact experienced. >> 4. I have been challenged to provide financial info regarding >> financial impact of voice on income regarding corporate/education >> efforts (LL could perhaps design better survey forms to tease that >> info out, I can only tell about my own efforts which is skewed >> because of my audience: federal agencies. I would be using another >> platform if SL did not integrate voice because this is one of the >> primary requirements from RFPs or when you are putting in a >> competitive bid while facing other VR platforms such as Forterra >> which had lipsync for years and better web integration ) So it is not >> entirely mesmerizing why LL has ignored the voice controversy perhaps >> because corporations or feds don't pay in Lindens. >> 5. Enabling voice should trigger lipsync automatically (no need to >> overload UI) >> 6. On a related note, I found that there was a solution for the space >> navigator especially regarding vehicle controls in SL and the >> integration of that patch is supposed to be for the next main client >> [keeping fingers crossed, hope no controversy about this one :)]. >> Turns out my audience also prefer for some reason this device (I >> prefer the keyboard). >> 7. The plugin idea is great except that it will require deeper >> changes and we are still refactoring right? so while I would love to >> see it happen, I dont think those tiny incremental changes should be >> left out. >> >> There is therefore some understandable frustration regarding the time >> it takes for the patches to be integrated (If you find out when Aimee >> actually got a handle on this space navigator - vehicles problem, you >> will understand the frustration). It is clear that there are many >> items with high priority (HTML on a prim is a requirement...for e.g. >> and we it's coming any time :) but hey I think these little >> incremental improvements are worthwhile. And yes btw, Babbage Linden >> (Technical Director?) did mention Mike's work recently, as an example >> of user contribution, in one of his talks recently. So I think they >> might be more than a few people who like this stuff. >> >> MG >> >> On Wed, Apr 29, 2009 at 1:51 PM, Mike Monkowski >> > wrote: >> >> Lip sync does not use any more CPU power than the blinking of the >> eyes >> does. It does not affect bandwidth at all. Perhaps you're >> confusing >> voice chat with lip sync. >> >> Mike >> >> Ann Otoole wrote: >> > How ridiculous that anyone would consider forcing the default >> to enabled >> > on anything that would increase CPU or Bandwidth. >> > >> > All defaults should be OFF on anything that compounds the problems >> > related to system compatibility and ISP efforts to kill >> utilization. >> > Such as voice. >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090501/d68bbc6a/attachment-0001.htm From philip at lindenlab.com Fri May 1 11:05:08 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Fri, 01 May 2009 11:05:08 -0700 Subject: [sldev] About the http-texture project In-Reply-To: References: <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> <493033a70904300743m45c9e8bdg1dd8a37d7e8ea95f@mail.gmail.com> <49F9C142.7060904@watson.ibm.com><6DA98012-931B-4B4F-8BD7-5D3249FD073E@lindenlab.com><49F9F135.7070007@watson.ibm.com> Message-ID: <49FB39D4.1090700@lindenlab.com> Philippe's explanation (below) is great! I would add: I think it is appropriate that we don't yet have a well-defined process! Every open source project is a bit different, and this one will probably be even more different given the scope of SL, the complexity of the system, and the fact that we are co-designing many new capabilities that are as yet unimagined. So it is OK that we don't have all the wiki docs in place or ducks in a row. Let's work together through a few projects and document what makes the most sense. Philip Philippe Bossut (Merov Linden) wrote: > Hi Mike, > > On Apr 30, 2009, at 11:43 AM, Mike Monkowski wrote: > > >> Philippe Bossut (Merov Linden) wrote: >> >>> Not sure which missing documentation you're referring to but we >>> have 3 at the moment: >>> >> OK, let's say Joe Sldev (I think the name is Serbian) has a great >> idea that he want's to get into the SL viewer. >> >> Is this new open source viewer (aka http-texture) his new open >> source portal or is it a sneaky underhanded backdoor to infiltrate >> the viewer codebase? >> > > Our goal with the OSS viewer has been made clear by Philip (see https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts) > . We do hope that most of the innovations battle tested here will > eventually make it to the official viewer codebase but things that are > clearly not mainstream enough or not very popular with this community > won't simply make it there and that's ok. People will still be able to > get those features in the "Second Life OSS" download though. > > So, for Joe Sldev, the "Second Life OSS" project is the right one to > get his new feature in a fairly well distributed viewer, tested and > amended by a knowledgeable community, you. > > >> He has a PJIRA entry with a patch file. How does that make its way >> to the SVN project? Does he have to worry about getting it into the >> SVN branch? Are there gatekeepers along the way? What if someone >> objects? Do we end up with SVN wars like Wiki wars? >> > > It's like almost any other FLOSS project: there is a group of > *committers* that do have commit privileges to the svn tree. The big > difference with the "old LL way of doing things" is that this group of > committers has Lindens *and* non-Lindens. After submitting his > contribution to the JIRA, Joe Sldev should engage folks on this > mailing list to get support for his feature: are people interested by > the feature, is this a worthy issue to fix. If there is community > support and a good review of his code from committers, the patch will > be taken in and committed by one of the committers. Eventually, if Joe > Sldev does quite a bit of good contributions in line with the project, > the committers will propose Joe to become a committer himself. The > committers group grows by co-optation only. > > If someone objects (and if our community is alive, there *will* be > someone to object...), we debate and try to reach a consensus on this > list. If there's a really contentious decision to be made (split > debate), Philip, our BDFL (Benevolent Dictator For Life), will weight > in and make the decision. > > As for avoiding wars, we won't have SVN wars since the group of > committers will be co-opted. Obviously, the committers will be careful > co-opting only people who share their view and philosophy of > development. If one committer will all of a sudden commit > controversial patches with no respect for due debate or the general > direction of the project (as decided by the BDFL), he or she'll see > his/her commit rights revoked. The BDFL has full authority in that > matter. > > >> When the project gets merged to the branch, and the branch to the >> trunk, and the trunk to the RC, and the RC to the standard viewer, >> who does all that merging? Does anyone test it along the way? Does >> everything in the project get merged at once, or do selected patches >> get merged separately? >> > > That's a lot of question and each project (RC, maint, etc...) has its > own way of ensuring quality and consistency of its project, mitigating > agility vs prudence. As far as the merge back to the official viewer > of "Second Life OSS" feature is concerned, that'll be up to the LL > viewer team to cherry pick and merge patches/commits separately. I'll > admit that this is not easy to do. Making this more manageable is one > of the big reason for the push to hg (mercurial) which does make > merges from various sources much more easier than svn. > > >> Does anybody document what's going on? Does anyone even document >> the new or modified functionality? Where? At what point of the >> process? >> > > Every feature *must* have a JIRA attached with relevant doc and test > plan. If too big for the JIRA, the JIRA record should point to a wiki > doc. Contributors should expect to document their code, write test > plans, etc... I'm not for writing a long list of enforced rules and > regulations as we don't know yet how deep those patches will be. If I > have to make a guess based on the ones I've seen from Robin Aimee and > a couple of others, I'm not expecting this to become super process > heavy. As a general philosophy, we should all strive for a high level > of quality for contributions. Writing a patch and throwing it to JIRA > hoping others will write the code documentation, test plan, build and > test the code, etc... won't get Joe Sldev very far. > > Cheers, > - Merov > _______________________________________________ > 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/20090501/38f63dd8/attachment.htm From gp at metafuturing.com Fri May 1 11:09:53 2009 From: gp at metafuturing.com (Giulio Prisco) Date: Fri, 1 May 2009 20:09:53 +0200 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FB392D.3060004@lindenlab.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> Message-ID: <68afc94f0905011109g482a85c7m150baa7ccd7a3a9e@mail.gmail.com> I am generally in favor of lipsync as something that gives a more real look&feel to SL. In brickspace, we are used to seeing people moving lips and without green waves! I think Philip is right: lipsync on by default, with a simple opt-out mechanism. On Fri, May 1, 2009 at 8:02 PM, Philip Rosedale wrote: > * As to the question of whether to default it on or off, clearly it is a > complex issue. I'd say lets default it on, and make sure it is easy to find > the way to turn it off. For some use cases it is very cool, lending > immersion and cueing as to speaker. For other cases you will want it off. -- -- Giulio Prisco gp at metafuturing.com metafuturing S.L. http://metafuturing.com/ C Juan Ram?n Jim?nez 8-1 Complejo Eurobuilding 28036 Madrid - Spain Phone (34) 91 18 19 147 Fax (34) 91 350 47 52 Cell (34) 610 536 144 From moriz.gupte at gmail.com Fri May 1 11:57:02 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Fri, 1 May 2009 12:57:02 -0600 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <68afc94f0905011109g482a85c7m150baa7ccd7a3a9e@mail.gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <68afc94f0905011109g482a85c7m150baa7ccd7a3a9e@mail.gmail.com> Message-ID: Here's my argument for not even having a UI control point for lipsync: I think a lot of times, the interface reflects the chaos of unanticipated evolutions/emergences of 'features'/'requirements' and I think this leads to very unfriendly UIs. When we look at a UI, the primary function of a UI should suggest 'function'. At best, it should not reveal the messy history of technical solutions (big fan of bauhaus, when u see something, its form should at best suggest function). So I think when we want to simplify a UI, may be we should ask: Is this check box here because some people dont really need it, or whether it is there... because we missed to implement that (whatever it is) in the first place and people built things around this situation and now will be unhappy once this feature is in by default. In passing, not entirely different problem: the skin issue not facing SL ... there is an understandable uproar against improvements regarding skin (beacause all skin businesses will be hit) that LL developers are trying to introduce. Of course, if it ultimately turns out that lipsynch has a footprint that slows everything down...then we should keep it in advanced where it belongs (and this does not seem to be the case). In other words, I think the lipsync issue is a fragment of an ill-fragmented problem (this fragmentation reflects the 'chaos' of implementation processes or lack of staff or interest to implement it in the first place). So the question whether to have lipsync or not is a non-question from a strictly UI perspective. When one looks back, it makes little sense, as Ron and others pointed out, to represent an avatar producing voice sounds with no lips moving: 'ventriloquist effect'. I think folks who need lipsync off can perhaps go in the debug settings and set it off from there...I would not favor a check box solution which would already overload not only the UI, or put additonal unnecessary load on user manuals, orientation processes etc. Regarding, civility on the list, I apologize to anyone that I may have offended. Gordon, I truly did not want to be condescending. I truly believe we are all one and it's only our egoes/bundles of conditioning that separate us (and these are illusions). I was also wondering if it is appropriate to voice on this list things we would like to see, even if we may not have the time or resources to implement and demonstrate them. I certainly dont want to turn the list into wish list ( I guess it is a judgement call for me to make, but if you have ideas to help me, let me know). I feel that in the past, I had submitted ideas on different LL venues... but they did not seem to fit in those (e.g. UI suggestions: video bubbles, navigation aids, capturing/sharing of avatar spatial cognitive maps) R On Fri, May 1, 2009 at 12:09 PM, Giulio Prisco wrote: > I am generally in favor of lipsync as something that gives a more real > look&feel to SL. In brickspace, we are used to seeing people moving > lips and without green waves! > > I think Philip is right: lipsync on by default, with a simple opt-out > mechanism. > > On Fri, May 1, 2009 at 8:02 PM, Philip Rosedale > wrote: > > > * As to the question of whether to default it on or off, clearly it is a > > complex issue. I'd say lets default it on, and make sure it is easy to > find > > the way to turn it off. For some use cases it is very cool, lending > > immersion and cueing as to speaker. For other cases you will want it > off. > -- > -- > Giulio Prisco > gp at metafuturing.com > metafuturing S.L. > http://metafuturing.com/ > C Juan Ram?n Jim?nez 8-1 > Complejo Eurobuilding > 28036 Madrid - Spain > Phone (34) 91 18 19 147 > Fax (34) 91 350 47 52 > Cell (34) 610 536 144 > _______________________________________________ > 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 Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2 , Blog: http://snipurl.com/3p5op , Play2Train: http://www.play2train.org ----- The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge- Stephen Hawking and many others who found light through the cracks of knowledge. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090501/643adfe7/attachment-0001.htm From melinda at superliminal.com Fri May 1 12:05:27 2009 From: melinda at superliminal.com (Melinda Green) Date: Fri, 01 May 2009 12:05:27 -0700 Subject: [sldev] [META] indentation fixes/changes and merging In-Reply-To: References: <49FAF889.2040200@boroon.dasgupta.ch> <49FB260C.7010408@boroon.dasgupta.ch> Message-ID: <49FB47F7.50207@superliminal.com> Soft wrote: > On Fri, May 1, 2009 at 11:40 AM, Boroondas Gupte > wrote: > >> Soft schrieb: >> >>> On Fri, May 1, 2009 at 8:26 AM, Boroondas Gupte >>> wrote: >>> >>> >>>> If I remember correctly, Linden Lab once discouraged us from sending them >>>> indentation-only patches, because the overhead to review and import them was >>>> too much in relation to the benefit of such changes. Instead we should clean >>>> up code while working on the specific parts for bigger bugs of features. >>>> This is quite some while ago, so I don't know if that's still the current >>>> recommendation. >>>> >>>> >>> The problem with indentation patches isn't review, it's merging. >>> >>> If 200 lines in one file are indented, they all show up as changed. >>> What happens when that's merged with a branch without the indentation >>> change, but where one line in that soup of 200 was changed? It's very >>> likely that the change with a code effect will get lost without a >>> very, very careful eye. >>> >> Hmm ... indeed. Forgot about that one. :-( >> >>> It's also going to slow down the merge, which >>> extends our critical path. >>> >>> LL's own future move to mercurial or better merge tools may change >>> that. The remaining question would then be review time. Right now, a >>> bunch of formatting changes wouldn't make it back to the tree, though. >>> >>> >> I fear hg (or any other modern SCM) won't help very much here, as their >> automatic merging is still line-based, so this will almost always >> trigger a merge conflict to be resolved manually. I wonder how other big >> projects handle this issue, as keeping false indentation in the code >> until the specific part of code is touched for another reason can't be >> the proper solution. >> > > Honestly, I think they handle it by not having branches spend so long > diverged from trunk/. The chances of merge conflicts go up > exponentially with the number of changes made independently. Better > compartmentalization of the code would also help. It would become more > likely that cleanup changes could be made in the branch where other > development on that code is happening. > > The take-away I get from this is that cleanup is hard if the code is > already poorly structured. So that underscores the importance of > cleaning up code when touching the code for other purposes. Maybe this > means the best way for you to go forward with your project would be to > look for ways to link pools of janitorial work to other patch > submissions touching the same code. I love Boroondas' intentions and I agree with Soft's analysis but I don't agree completely with his conclusion. If you are only going to clean up the actual lines you need to change, then that will not cause diff obfuscation, but the temptation to then also clean up neighboring lines becomes huge and leads to the problem you're trying to avoid. The solution I prefer is to submit changes in two commits. In the first one I do all the clean-up of the whole general area in which I intend to change and commit that with a standard comment such as "Whitespace only. No functional change." I then do my substantive work and check it in as usual. That way the diffs will always make sense. When looking at the whitespace diffs, you can confirm at a glance that nothing substantive changed, and when looking at the substantive diff, you won't see any whitespace changes highlighted. Note that this makes code reviews much easier too. I don't feel that the whitespace commits should require code reviews, and I certainly don't want my reviewers to be distracted by whitespace changes while trying to understand my substantive changes. So my proposal for our situation is: 1) Don't make whitespace fixes if you don't also have substantive changes to make to that area of code. 2) Commit all your whitespace fixes separately from your substantive changes. -Melinda From merov at lindenlab.com Fri May 1 12:14:10 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Fri, 1 May 2009 12:14:10 -0700 Subject: [sldev] Open Source Meeting, 2PM PDT, Hippotropolis In-Reply-To: References: <3B7F46F8-2F96-49B9-B62F-879D3BBD3B34@lindenlab.com><49F9CA9A.2000103@watson.ibm.com> <49FA398A.5090105@watson.ibm.com> Message-ID: Thanks Q! I'll try to plug some of my post (about the Joe Sldev's scenario) into this. Cheers, - Merov On May 1, 2009, at 7:58 AM, Kent Quirk (Q Linden) wrote: > Thanks for the outline, Mike. > > I've created a version of it here from comments Merov has made plus a > few of my own: > > https://wiki.secondlife.com/wiki/SLDev_Open_Source_Viewer > > I'd encourage Lindens -- especially Merov and Philip -- to expand on > it. > > Q > > On Apr 30, 2009, at 7:51 PM, Mike Monkowski wrote: > >> As I warned :-) at the meeting today, I'm making up documentation >> for this new Open Source Viewer process. You can see the work in >> progress at http://wiki.secondlife.com/wiki/User:Mm_Alder/SLDev_Open_Source_Viewer >> Feel free to edit whatever you like. I'm only doing this because >> no one else would. :-) >> >> Mike >> >> Mike Monkowski wrote: >>> I added: >>>> # Can we get better documentation on the open source viewer >>>> project (aka http-texture)? Is there anyone other than me who >>>> would be interested in open code reviews for this project? Mm >>>> Alder 15:57, 30 April 2009 (UTC) >>> Kent Quirk (Q Linden) wrote: >>>> Please add items to the agenda if you wish: >>>> >>>> http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda >>>> >>>> I'll be hosting today. > > _______________________________________________ > 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 May 1 12:21:03 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 1 May 2009 21:21:03 +0200 Subject: [sldev] http-texture project - how far until complete? (this will totally Rawk SL!) In-Reply-To: <0497D618-02C8-4726-8CC0-0399C684D5E7@lindenlab.com> References: <20090430192152.557023DBC449@tammy.lindenlab.com> <0497D618-02C8-4726-8CC0-0399C684D5E7@lindenlab.com> Message-ID: <20090501192103.GA9084@alinoe.com> On Thu, Apr 30, 2009 at 12:57:03PM -0700, Philippe Bossut (Merov Linden) wrote: > If we had infinite bandwidth and CPU, we wouldn't need a map at all: > just fly high and look down, go where you want. From a realistic That is not entirely true... There are lots of private, isolated sims that use the fact that *despite* that they are on a map, say, at 512 meter distance from the "next" sim-- they are really a world apart. I can set a marker in the map of my neighbor sim and SEE the red beam in the virtual world... but when I cam over there, it's just sea. That is how it should be: a private sim should be totally cut off from the rest of the world. In fact, it shouldn't even BE on "the map"!. Maybe that is the way to go... Don't have ONE map for all sims, but have as many maps as there are areas where you can actually fly (or cam) around between sims. Then only allow people to see a map if they have access in the first place. Only then you can allow people to zoom and zoom and zoom and actually be there. -- Carlo Wood From ron at involve3d.com Fri May 1 12:38:03 2009 From: ron at involve3d.com (Ron Blechner) Date: Fri, 1 May 2009 15:38:03 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FB392D.3060004@lindenlab.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> Message-ID: > We are still at the point where the 'uncanny valley' nature of the feature > can make it unnerving, and that problem is unlikely to be easily solved soon > in realtime with low CPU load. This is a really interesting point, as avatars I've seen in world range from clear to the left of the uncanny valley, right through it, to acceptably beyond it to the right. It's a large part of the reason my avatar is still using default skin texture, wears sunglasses, and has cartoony hair. There's no easy answer to this issue, as even as technology changes, people will still have a range of different avatar looks. My reasonable guess, based from my experience with lipsync in other virtual world platforms and games, is that lipsync alone does not cause much of an issue with the "freaky factor" as one may call it. I believe facial expressions are a much trickier issue in regards to the uncanny valley. (That said, I still think its absolutely essential for the future of virtual worlds that facial expressions get a move on.) I wonder, then, what sorts of evidence / research is needed? Maybe this is a case where we all can just "do our homework" - there's plenty of machinima on YouTube using Second Life and lipsync and without it. And it's not difficult to find a variety of different avatars - from cartoony to hyper-realistic - in which we can look at how lipsync looks ourselves. Personally, I think doing this kind of research will absolutely reinforce the idea of putting lipsync on by default, but I'm certainly biased. :) ... I might also add that non-human avatars have used Animation Overrider tools to replace the typing and trigger prim-animations that move mouths. (Yes, I'm referencing the furries!) I'd also be interested to hear anyone's first-hand experiences where the lipsync is unnerving; Philip, have you had that experience yourself? -Ron / Hiro CTO, Involve, Inc www.involve3d.com SL: Hiro Pendragon From monkowsk at watson.ibm.com Fri May 1 15:52:57 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri, 01 May 2009 18:52:57 -0400 Subject: [sldev] Open Source Meeting, 2PM PDT, Hippotropolis In-Reply-To: References: <3B7F46F8-2F96-49B9-B62F-879D3BBD3B34@lindenlab.com> <49F9CA9A.2000103@watson.ibm.com> <49FA398A.5090105@watson.ibm.com> Message-ID: <49FB7D49.5080305@watson.ibm.com> Rats! I just finished filling it in myself. I'll have a look at merging the two. Mike Kent Quirk (Q Linden) wrote: > Thanks for the outline, Mike. > > I've created a version of it here from comments Merov has made plus a > few of my own: > > https://wiki.secondlife.com/wiki/SLDev_Open_Source_Viewer > > I'd encourage Lindens -- especially Merov and Philip -- to expand on it. > > Q > > On Apr 30, 2009, at 7:51 PM, Mike Monkowski wrote: > >> As I warned :-) at the meeting today, I'm making up documentation for >> this new Open Source Viewer process. You can see the work in >> progress at >> http://wiki.secondlife.com/wiki/User:Mm_Alder/SLDev_Open_Source_Viewer >> Feel free to edit whatever you like. I'm only doing this because no >> one else would. :-) >> >> Mike >> >> Mike Monkowski wrote: >> >>> I added: >>> >>>> # Can we get better documentation on the open source viewer project >>>> (aka http-texture)? Is there anyone other than me who would be >>>> interested in open code reviews for this project? Mm Alder 15:57, >>>> 30 April 2009 (UTC) >>> >>> Kent Quirk (Q Linden) wrote: >>> >>>> Please add items to the agenda if you wish: >>>> >>>> http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda >>>> >>>> I'll be hosting today. > > > From monkowsk at watson.ibm.com Fri May 1 16:08:23 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri, 01 May 2009 19:08:23 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FB392D.3060004@lindenlab.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com><49F77537.8010609@w atson.ibm.com><493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com><49F867E1.6040805@watson.ibm.com><784490.3996.qm@web59104.mail.re1.yahoo.com><49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> Message-ID: <49FB80E7.9090205@watson.ibm.com> Philip Rosedale wrote: > * We need a clear and discoverable place in the UI where this feature > can be enabled and disabled. Probably prefs. Can someone take on that > design and coding? Advanced-> isn't the right home for this. We > should do that work properly and well to complete this feature. At least for the time being, I think it should be left in Advanced. Torley's video describing it points to the Advanced menu. After a while, it might make sense to move it, but to change the default condition and move the UI control at the same time seems a bit devious. > * Can someone (Mike?) add a bit more detail on the jira task to > defend/review that the CPU impact is strictly capped. For example, what > is the LOD behavior if there are 100 avatars all talking at the same > time. We have LOD tricks for various rendering aspects of the system, > do they correctly carry through? Does the CPU load of the feature vary > by GPU? I think we need this level of documentation. Lip sync gets intensity indicators from voice chat the same way that the green indicators do, so that is zero overhead. All it does is change the morph weights for two localized morphs, very similar to eye blinks. I have used the Fast Timers to try to measure any difference, but see none. I never tried 100 avatars talking at once. The most I ever heard speaking at once is about three. Yes, the LOD processing stays exactly the same. The two new morphs were derived from existing morphs. > * As to the question of whether to default it on or off, clearly it is a > complex issue. I'd say lets default it on, and make sure it is easy to > find the way to turn it off. For some use cases it is very cool, > lending immersion and cueing as to speaker. For other cases you will > want it off. We are still at the point where the 'uncanny valley' > nature of the feature can make it unnerving, and that problem is > unlikely to be easily solved soon in realtime with low CPU load. Hmmm. Faces that don't move while talking are unnerving to me, like the commercials with the mannequins. Creepy. > As a final note, I'd say this is a good example of a tough topic where > the right call is unclear and discussion and debate is appropriate. > Also a good case of where if need be, I can just make a call and we move > on and see what happens. Given that, why the rudeness I am seeing > here? I don't see a need to be insulting to each other over this > topic. Maybe I've missed some painful history here, but can't see how > this is helping us move forward. I wouldn't work internally on projects > at LL with colleagues that were overly rude, I don't see why it should > be any different here! I haven't sensed any rudeness from others, just open discussion. If I have been rude, I apologize. I did not intend to be. Mike From monkowsk at watson.ibm.com Fri May 1 16:10:04 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri, 01 May 2009 19:10:04 -0400 Subject: [sldev] Open Source Meeting, 2PM PDT, Hippotropolis In-Reply-To: References: <3B7F46F8-2F96-49B9-B62F-879D3BBD3B34@lindenlab.com><49F9CA9A.2000103@watson.ibm.com> <49FA398A.5090105@watson.ibm.com> Message-ID: <49FB814C.5040300@watson.ibm.com> Merov, I used a lot of your note in my version. I'll try to merge it together with Q's. Mike Philippe Bossut (Merov Linden) wrote: > Thanks Q! > > I'll try to plug some of my post (about the Joe Sldev's scenario) into > this. > > Cheers, > - Merov > > On May 1, 2009, at 7:58 AM, Kent Quirk (Q Linden) wrote: > > >>Thanks for the outline, Mike. >> >>I've created a version of it here from comments Merov has made plus a >>few of my own: >> >>https://wiki.secondlife.com/wiki/SLDev_Open_Source_Viewer >> >>I'd encourage Lindens -- especially Merov and Philip -- to expand on >>it. >> >> Q >> >>On Apr 30, 2009, at 7:51 PM, Mike Monkowski wrote: >> >> >>>As I warned :-) at the meeting today, I'm making up documentation >>>for this new Open Source Viewer process. You can see the work in >>>progress at http://wiki.secondlife.com/wiki/User:Mm_Alder/SLDev_Open_Source_Viewer >>>Feel free to edit whatever you like. I'm only doing this because >>>no one else would. :-) >>> >>>Mike >>> >>>Mike Monkowski wrote: >>> >>>>I added: >>>> >>>>># Can we get better documentation on the open source viewer >>>>>project (aka http-texture)? Is there anyone other than me who >>>>>would be interested in open code reviews for this project? Mm >>>>>Alder 15:57, 30 April 2009 (UTC) >>>> >>>>Kent Quirk (Q Linden) wrote: >>>> >>>>>Please add items to the agenda if you wish: >>>>> >>>>>http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda >>>>> >>>>>I'll be hosting today. >> >>_______________________________________________ >>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 GordonWendt at gmail.com Fri May 1 16:12:40 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Fri, 1 May 2009 19:12:40 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FB80E7.9090205@watson.ibm.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> Message-ID: <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> No no and no, if it's optional then by all means hide it in advanced but if you have it switched on by default you have to have an easy way to turn it on and off which means the preferences, otherwise don't turn it on by default. -Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090501/4d78e5af/attachment.htm From q at lindenlab.com Fri May 1 21:42:29 2009 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Sat, 2 May 2009 00:42:29 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> Message-ID: Given the excessive complexity of the preferences dialog already, we should take every opportunity to remove things from prefs, and there should be a VERY high bar for adding anything to prefs. It's all too easy for open projects to grow massive preferences systems and configuration files because the outcome of most feature debates is to compromise and add a preference. In this case, especially given that it already lives in Advanced, I strongly recommend we not move it to Preferences. Q On May 1, 2009, at 7:12 PM, Gordon Wendt wrote: > No no and no, if it's optional then by all means hide it in advanced > but if you have it switched on by default you have to have an easy > way to turn it on and off which means the preferences, otherwise > don't turn it on by default. > From gigstaggart at gmail.com Fri May 1 23:38:00 2009 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat, 02 May 2009 02:38:00 -0400 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <9bb32d430904300612x1274bfa8y31a764f5c6009f53@mail.gmail.com> References: <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> <9bb32d430904300237w5db5ce6apcc67ef0141d408@mail.gmail.com> <9bb32d430904300601g37b4a386rc74099cb4c42b746@mail.gmail.com> <9bb32d430904300604i58b2d0f5l6eccfd1e4470210a@mail.gmail.com> <49F9A242.8040408@streamsense.net> <9bb32d430904300612x1274bfa8y31a764f5c6009f53@mail.gmail.com> Message-ID: <49FBEA48.1050008@gmail.com> Ambrosia wrote: > On a note, with the FLOSS exception not including the licenses for > Quicktime, FMOD and Vivox..I sense a massive oversight on part of LL > here. This quite frankly renders third party viewers useless for most > residents. Do you think this was unintentional? -Jason From tigrospottystripes at gmail.com Sat May 2 04:24:55 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 02 May 2009 08:24:55 -0300 Subject: [sldev] Anyone from the time of Dynamic Reflections still here? Message-ID: <49FC2D87.3020602@Gmail.com> I would like to know what happened exactly, at first it worked perfectly for me, then it stopped being supported cause it was crashing some people, then it started working worse and worse for me and eventually I couldn't even find it on the client at all. Is any Linden around that was around back when it all took place and knows the details of what happened? From GordonWendt at gmail.com Sat May 2 05:55:39 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Sat, 2 May 2009 08:55:39 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> Message-ID: <493033a70905020555p601477f5t810c7417cc95b6b0@mail.gmail.com> Kent, then don't put it on by default. You can't really have it both ways, if you have it on by default then there has to be an easy way to turn it on and off and advanced is not an easy way. I agree that prefs is already overcrowded but if you can't spare room in prefs for new items then maybe STOP PUTTING NEW FEATURES ON BY DEFAULT. The caps are meant just to emphasize my point btw not to be rude. -Gordon On Sat, May 2, 2009 at 12:42 AM, Kent Quirk (Q Linden) wrote: > Given the excessive complexity of the preferences dialog already, we should > take every opportunity to remove things from prefs, and there should be a > VERY high bar for adding anything to prefs. It's all too easy for open > projects to grow massive preferences systems and configuration files because > the outcome of most feature debates is to compromise and add a preference. > > In this case, especially given that it already lives in Advanced, I > strongly recommend we not move it to Preferences. > > Q > > > > On May 1, 2009, at 7:12 PM, Gordon Wendt wrote: > > No no and no, if it's optional then by all means hide it in advanced but >> if you have it switched on by default you have to have an easy way to turn >> it on and off which means the preferences, otherwise don't turn it on by >> default. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090502/f7761a3b/attachment.htm From moriz.gupte at gmail.com Sat May 2 07:53:26 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Sat, 2 May 2009 08:53:26 -0600 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <493033a70905020555p601477f5t810c7417cc95b6b0@mail.gmail.com> Message-ID: Gordon, let's look at history. Color TVs. In particular, evolution from black and white TV to color TV. My grandma used to have a color TV set. It had all kinds of controls that I cannot dream of having today. The controls reflected the unanticipated technological features that got injected into the TV set. You had Red Green Blue controls (each with dials), Another color control, in passing, a full blown equalizer for sound (let's not go there). For some people color was a luxury...or even something to mess up the 'quality' of the artistic experience. Evolution has a tendency to kill things that are not needed. Today I find it hard to find a TV set with an easily accessible control to turn off color. This is just an example. We can look at every device in the real world and trace back the history of its interface and u will see that. From cars, planes to anything... OK. This is my last word on this topic, promise.... we have already discussed about face processing and its importance in immersion, turn taking, expressiveness, footprint issues..and I think there are good chances the right decision will be made. On Sat, May 2, 2009 at 8:49 AM, Ramesh Ramloll wrote: > . > > On Sat, May 2, 2009 at 6:55 AM, Gordon Wendt wrote: > >> Kent, then don't put it on by default. You can't really have it both >> ways, if you have it on by default then there has to be an easy way to turn >> it on and off and advanced is not an easy way. I agree that prefs is >> already overcrowded but if you can't spare room in prefs for new items then >> maybe STOP PUTTING NEW FEATURES ON BY DEFAULT. The caps are meant just to >> emphasize my point btw not to be rude. >> >> -Gordon >> >> >> >> On Sat, May 2, 2009 at 12:42 AM, Kent Quirk (Q Linden) wrote: >> >>> Given the excessive complexity of the preferences dialog already, we >>> should take every opportunity to remove things from prefs, and there should >>> be a VERY high bar for adding anything to prefs. It's all too easy for open >>> projects to grow massive preferences systems and configuration files because >>> the outcome of most feature debates is to compromise and add a preference. >>> >>> In this case, especially given that it already lives in Advanced, I >>> strongly recommend we not move it to Preferences. >>> >>> Q >>> >>> >>> >>> On May 1, 2009, at 7:12 PM, Gordon Wendt wrote: >>> >>> No no and no, if it's optional then by all means hide it in advanced but >>>> if you have it switched on by default you have to have an easy way to turn >>>> it on and off which means the preferences, otherwise don't turn it on by >>>> default. >>>> >>>> >> >> _______________________________________________ >> 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 > Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2, Blog: > http://snipurl.com/3p5op , Play2Train: http://www.play2train.org > ----- > The greatest enemy of knowledge is not ignorance, it is the illusion of > knowledge- Stephen Hawking and many others who found light through the > cracks of knowledge. > > > > -- Rameshsharma Ramloll PhD Research Assistant Professor Idaho State University, PocatelloTel: 208-282-5333 Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2 , Blog: http://snipurl.com/3p5op , Play2Train: http://www.play2train.org ----- The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge- Stephen Hawking and many others who found light through the cracks of knowledge. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090502/7cbbef45/attachment.htm From ron at involve3d.com Sat May 2 08:11:19 2009 From: ron at involve3d.com (Ron Blechner) Date: Sat, 2 May 2009 11:11:19 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <493033a70905020555p601477f5t810c7417cc95b6b0@mail.gmail.com> Message-ID: Yeah, it'd be like saying, "Let's not put cruise control in a car because we can't figure out where to put the button." I don't see the need to put it in preferences at all, as it's such an integral feature with voice. But that question seems ... secondary ... to whether lipsync is on by default. -Ron / Hiro On Sat, May 2, 2009 at 10:53 AM, Moriz Gupte wrote: > Gordon, let's look at history. Color TVs. In particular, evolution from > black and white TV to color TV. My grandma used to have a color TV set. It > had all kinds of controls that I cannot dream of having today. The controls > reflected the unanticipated technological features that got injected into > the TV set. You had Red Green Blue controls (each with dials), Another color > control, in passing, a full blown equalizer for sound (let's not go there). > For some people color was a luxury...or even something to mess up the > 'quality' of the artistic experience. Evolution has a tendency to kill > things that are not needed. Today I find it hard to find a TV set with an > easily accessible control to turn off color. > This is just an example. We can look at every device in the real world and > trace back the history of its interface and u will see that. From cars, > planes to anything... > > OK. This is my last word on this topic, promise.... we have already > discussed about face processing and its importance in immersion, turn > taking, expressiveness, footprint issues..and I think there are good chances > the right decision will be made. > > On Sat, May 2, 2009 at 8:49 AM, Ramesh Ramloll wrote: >> >> . >> >> On Sat, May 2, 2009 at 6:55 AM, Gordon Wendt >> wrote: >>> >>> Kent, then don't put it on by default.? You can't really have it both >>> ways, if you have it on by default then there has to be an easy way to turn >>> it on and off and advanced is not an easy way.? I agree that prefs is >>> already overcrowded but if you can't spare room in prefs for new items then >>> maybe STOP PUTTING NEW FEATURES ON BY DEFAULT.? The caps are meant just to >>> emphasize my point btw not to be rude. >>> >>> -Gordon >>> >>> >>> On Sat, May 2, 2009 at 12:42 AM, Kent Quirk (Q Linden) >>> wrote: >>>> >>>> Given the excessive complexity of the preferences dialog already, we >>>> should take every opportunity to remove things from prefs, and there should >>>> be a VERY high bar for adding anything to prefs. It's all too easy for open >>>> projects to grow massive preferences systems and configuration files because >>>> the outcome of most feature debates is to compromise and add a preference. >>>> >>>> In this case, especially given that it already lives in Advanced, I >>>> strongly recommend we not move it to Preferences. >>>> >>>> ? ? ? ?Q >>>> >>>> >>>> On May 1, 2009, at 7:12 PM, Gordon Wendt wrote: >>>> >>>>> No no and no, if it's optional then by all means hide it in advanced >>>>> but if you have it switched on by default you have to have an easy way to >>>>> turn it on and off which means the preferences, otherwise don't turn it on >>>>> by default. >>>>> >>> >>> >>> _______________________________________________ >>> 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 >> Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2 >> , Blog: http://snipurl.com/3p5op , Play2Train: http://www.play2train.org >> ----- >> The greatest enemy of knowledge is not ignorance, it is the illusion of >> knowledge- Stephen Hawking and many others who found light through the >> cracks of knowledge. >> >> >> > > > > -- > Rameshsharma Ramloll PhD Research Assistant Professor Idaho State > University, PocatelloTel: 208-282-5333 > Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2 , > Blog: http://snipurl.com/3p5op , Play2Train: http://www.play2train.org > ----- > The greatest enemy of knowledge is not ignorance, it is the illusion of > knowledge- Stephen Hawking and many others who found light through the > cracks of knowledge. > > > > > _______________________________________________ > 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 tateru.nino at gmail.com Sat May 2 09:24:46 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun, 03 May 2009 02:24:46 +1000 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <493033a70905020555p601477f5t810c7417cc95b6b0@mail.gmail.com> Message-ID: <49FC73CE.3070201@gmail.com> Perhaps the basic direction that this seems to be going in is that the preferences system needs a hard look at. Many applications have an order of magnitude more options than the SL viewer -- but their preferences UI and the organization of preferences and categories of preferences (and sometimes multiple levels of preferences) makes that all navigable. Does the whole prefs UI need revision - if the existing system isn't coping? Ron Blechner wrote: > Yeah, it'd be like saying, "Let's not put cruise control in a car > because we can't figure out where to put the button." I don't see the > need to put it in preferences at all, as it's such an integral feature > with voice. But that question seems ... secondary ... to whether > lipsync is on by default. > > -Ron / Hiro > > On Sat, May 2, 2009 at 10:53 AM, Moriz Gupte wrote: > >> Gordon, let's look at history. Color TVs. In particular, evolution from >> black and white TV to color TV. My grandma used to have a color TV set. It >> had all kinds of controls that I cannot dream of having today. The controls >> reflected the unanticipated technological features that got injected into >> the TV set. You had Red Green Blue controls (each with dials), Another color >> control, in passing, a full blown equalizer for sound (let's not go there). >> For some people color was a luxury...or even something to mess up the >> 'quality' of the artistic experience. Evolution has a tendency to kill >> things that are not needed. Today I find it hard to find a TV set with an >> easily accessible control to turn off color. >> This is just an example. We can look at every device in the real world and >> trace back the history of its interface and u will see that. From cars, >> planes to anything... >> >> OK. This is my last word on this topic, promise.... we have already >> discussed about face processing and its importance in immersion, turn >> taking, expressiveness, footprint issues..and I think there are good chances >> the right decision will be made. >> >> On Sat, May 2, 2009 at 8:49 AM, Ramesh Ramloll wrote: >> >>> . >>> >>> On Sat, May 2, 2009 at 6:55 AM, Gordon Wendt >>> wrote: >>> >>>> Kent, then don't put it on by default. You can't really have it both >>>> ways, if you have it on by default then there has to be an easy way to turn >>>> it on and off and advanced is not an easy way. I agree that prefs is >>>> already overcrowded but if you can't spare room in prefs for new items then >>>> maybe STOP PUTTING NEW FEATURES ON BY DEFAULT. The caps are meant just to >>>> emphasize my point btw not to be rude. >>>> >>>> -Gordon >>>> >>>> >>>> On Sat, May 2, 2009 at 12:42 AM, Kent Quirk (Q Linden) >>>> wrote: >>>> >>>>> Given the excessive complexity of the preferences dialog already, we >>>>> should take every opportunity to remove things from prefs, and there should >>>>> be a VERY high bar for adding anything to prefs. It's all too easy for open >>>>> projects to grow massive preferences systems and configuration files because >>>>> the outcome of most feature debates is to compromise and add a preference. >>>>> >>>>> In this case, especially given that it already lives in Advanced, I >>>>> strongly recommend we not move it to Preferences. >>>>> >>>>> Q >>>>> >>>>> >>>>> On May 1, 2009, at 7:12 PM, Gordon Wendt wrote: >>>>> >>>>> >>>>>> No no and no, if it's optional then by all means hide it in advanced >>>>>> but if you have it switched on by default you have to have an easy way to >>>>>> turn it on and off which means the preferences, otherwise don't turn it on >>>>>> by default. >>>>>> >>>>>> >>>> _______________________________________________ >>>> 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 >>> Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2 >>> , Blog: http://snipurl.com/3p5op , Play2Train: http://www.play2train.org >>> ----- >>> The greatest enemy of knowledge is not ignorance, it is the illusion of >>> knowledge- Stephen Hawking and many others who found light through the >>> cracks of knowledge. >>> >>> >>> >>> >> >> -- >> Rameshsharma Ramloll PhD Research Assistant Professor Idaho State >> University, PocatelloTel: 208-282-5333 >> Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2 , >> Blog: http://snipurl.com/3p5op , Play2Train: http://www.play2train.org >> ----- >> The greatest enemy of knowledge is not ignorance, it is the illusion of >> knowledge- Stephen Hawking and many others who found light through the >> cracks of knowledge. >> >> >> >> >> _______________________________________________ >> 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://www.massively.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090503/da957e3d/attachment.htm From bishopj at bishopphillips.com Sat May 2 10:03:08 2009 From: bishopj at bishopphillips.com (Jonathan Bishop) Date: Sun, 3 May 2009 03:03:08 +1000 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <061501c9c1e1$0a96ff00$1fc4fd00$@com><493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com><49F867E1.6040805@watson.ibm.com><784490.3996.qm@web59104.mail.re1.yahoo.com><49F8AFAD.3040007@watson.ibm.com><1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com><49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com><493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> Message-ID: <5A61915E6A00424F831DD423DBC574BC@neptune.priv> Q Said... "Given the excessive complexity of the preferences dialog already, we should take every opportunity to remove things from prefs, and there should be a VERY high bar for adding anything to prefs. It's all too easy for open projects to grow massive preferences systems and configuration files because the outcome of most feature debates is to compromise and add a preference. In this case, especially given that it already lives in Advanced, I strongly recommend we not move it to Preferences." Q ----- I could not disagree more - which is kind of unusual for me, since I rarely have much dispute with the LL team. Prefs is not yet even approaching complex, whereas the advanced menus are nuts. Put it in prefs. I absolutely agree with those arguing for lip synch being on by default. For effective immersion lip synch and a range of other behaviours are valuable in game play, but for other purposes it is or will rapidly become a defining requirement for acceptance among those who are not technophiles, or necessarily experienced VW users - eg lecture based education, corporate meetings, mixed mode 2D-3D delivery, and even for the more technically competent users engaged in machina (where lip synching must other wise be done with extensive post processing). However, as with voice, there will be those that object to it because it removes some of the characteristic, imagination and imposed creativity of the current experience (while replacing it with new dimensions of the same). So when first introduced it should be able to be turned off easily in prefs, and as it achieves normality and users have adapted their game-play/world-view to the new dimension, the control can be moved to advanced. As with the colour TV example - raised elsewhere, I hate losing control entirely, so I would not want the off option to totally disappear, but I think stuffing things into advanced as they become rarely used is the right way to go. Given the technical advice elsewhere that lip-synch has no impact on bandwidth, performance or CPU load, I can't see any advantage in denying its introduction, but I do acknowledge the variety of game play argument, and accept the importance of allowing people to preserve their current experience - so allow it to be turned off in prefs initially and migrate it to advanced over time. I do not use voice much normally (but then most of my SL time is spent alone building and scripting), but in training sessions, business meetings, sim management, and promotional work in SL I always use it - and in those spaces it makes an incredible difference. The biggest single impact is in acclimatizing new users - particularly real world clients - to SL so they can attend training or a meeting. Voice - and the current sound based flappy mouth thing that passes for lip synch at the moment, gives them a something familiar around which to anchor in an otherwise alien experience. Regards Jonathan Bishop From andromedaquonset at gmail.com Sat May 2 15:04:01 2009 From: andromedaquonset at gmail.com (Andromeda Quonset) Date: Sat, 02 May 2009 16:04:01 -0600 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <493033a70905020555p601477f5t810c7417cc95b6b0@mail.gmail.com> Message-ID: <49fcc3c5.27ba720a.128c.ffffc9ac@mx.google.com> Jumping in here on this conversation...... I am finding it incredible that a new feature would be suggested, be enabled by default, and then have it decided to not have a way of disabling the feature in preferences because someone thinks preferences menu is so crowded. If the lip sync "feature" MUST be added, to add it without some way of turning it off is unconscionable. If the preferences menu is not the place to disable it, then where do you proposed disabling it? Use a command line argument, perhaps? Or maybe I have to place a secret text file in some directory you specify that contains a keyword like NO_LIP_SYNC ? Maybe it can be linked to a new ctrl-alt-shift-function key combination? Or do you have a different idea? Andro At 08:53 AM 5/2/2009, you wrote: >Gordon, let's look at history. Color TVs. In particular, evolution >from black and white TV to color TV. My grandma used to have a color >TV set. It had all kinds of controls that I cannot dream of having >today. The controls reflected the unanticipated technological >features that got injected into the TV set. You had Red Green Blue >controls (each with dials), Another color control, in passing, a >full blown equalizer for sound (let's not go there). For some people >color was a luxury...or even something to mess up the 'quality' of >the artistic experience. Evolution has a tendency to kill things >that are not needed. Today I find it hard to find a TV set with an >easily accessible control to turn off color. >This is just an example. We can look at every device in the real >world and trace back the history of its interface and u will see >that. From cars, planes to anything... > >OK. This is my last word on this topic, promise.... we have already >discussed about face processing and its importance in immersion, >turn taking, expressiveness, footprint issues..and I think there are >good chances the right decision will be made. > >On Sat, May 2, 2009 at 8:49 AM, Ramesh Ramloll ><r.ramloll at gmail.com> wrote: >. > >On Sat, May 2, 2009 at 6:55 AM, Gordon Wendt ><GordonWendt at gmail.com> wrote: >Kent, then don't put it on by default. You can't really have it >both ways, if you have it on by default then there has to be an easy >way to turn it on and off and advanced is not an easy way. I agree >that prefs is already overcrowded but if you can't spare room in >prefs for new items then maybe STOP PUTTING NEW FEATURES ON BY >DEFAULT. The caps are meant just to emphasize my point btw not to be rude. > >-Gordon > > > >On Sat, May 2, 2009 at 12:42 AM, Kent Quirk (Q Linden) ><q at lindenlab.com> wrote: >Given the excessive complexity of the preferences dialog already, we >should take every opportunity to remove things from prefs, and there >should be a VERY high bar for adding anything to prefs. It's all too >easy for open projects to grow massive preferences systems and >configuration files because the outcome of most feature debates is >to compromise and add a preference. > >In this case, especially given that it already lives in Advanced, I >strongly recommend we not move it to Preferences. > > Q > > > >On May 1, 2009, at 7:12 PM, Gordon Wendt wrote: > >No no and no, if it's optional then by all means hide it in advanced >but if you have it switched on by default you have to have an easy >way to turn it on and off which means the preferences, otherwise >don't turn it on by default. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090502/42ae8125/attachment.htm From philip at lindenlab.com Sat May 2 15:43:24 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Sat, 02 May 2009 15:43:24 -0700 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> Message-ID: <49FCCC8C.9050502@lindenlab.com> I think that right direction is to assume that the majority of usage would favor having it on, but that it should be easy to turn off. Ron Blechner wrote: >> We are still at the point where the 'uncanny valley' nature of the feature >> can make it unnerving, and that problem is unlikely to be easily solved soon >> in realtime with low CPU load. >> > > This is a really interesting point, as avatars I've seen in world > range from clear to the left of the uncanny valley, right through it, > to acceptably beyond it to the right. It's a large part of the reason > my avatar is still using default skin texture, wears sunglasses, and > has cartoony hair. There's no easy answer to this issue, as even as > technology changes, people will still have a range of different avatar > looks. My reasonable guess, based from my experience with lipsync in > other virtual world platforms and games, is that lipsync alone does > not cause much of an issue with the "freaky factor" as one may call > it. I believe facial expressions are a much trickier issue in regards > to the uncanny valley. (That said, I still think its absolutely > essential for the future of virtual worlds that facial expressions get > a move on.) > > I wonder, then, what sorts of evidence / research is needed? Maybe > this is a case where we all can just "do our homework" - there's > plenty of machinima on YouTube using Second Life and lipsync and > without it. And it's not difficult to find a variety of different > avatars - from cartoony to hyper-realistic - in which we can look at > how lipsync looks ourselves. Personally, I think doing this kind of > research will absolutely reinforce the idea of putting lipsync on by > default, but I'm certainly biased. :) ... I might also add that > non-human avatars have used Animation Overrider tools to replace the > typing and trigger prim-animations that move mouths. (Yes, I'm > referencing the furries!) > > I'd also be interested to hear anyone's first-hand experiences where > the lipsync is unnerving; Philip, have you had that experience > yourself? > > -Ron / Hiro > > CTO, Involve, Inc > www.involve3d.com > SL: Hiro Pendragon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090502/aa87d187/attachment.htm From philip at lindenlab.com Sat May 2 15:49:38 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Sat, 02 May 2009 15:49:38 -0700 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FB80E7.9090205@watson.ibm.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com><49F77537.8010609@w atson.ibm.com><493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com><49F867E1.6040805@watson.ibm.com><784490.3996.qm@web59104.mail.re1.yahoo.com><49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> Message-ID: <49FCCE02.4080500@lindenlab.com> I'd like to see an implementation of turning on and off the lip sync feature that can be user tested to demonstrate that a new user of SL could be instructed to "Turn off the moving lips" and easy turn the feature off within 30 seconds or so. I agree that a software developer, or someone who is already familiar with the Advanced menus can do fine the way it is, but I'd like to move with this project toward a viewer that is "generally appealing" - meaning just as usable to a brand new user of Second Life as an existing one or an experienced developer. Does this make sense? Philip Mike Monkowski wrote: > Philip Rosedale wrote: >> * We need a clear and discoverable place in the UI where this >> feature can be enabled and disabled. Probably prefs. Can someone >> take on that design and coding? Advanced-> isn't the right home for >> this. We should do that work properly and well to complete this >> feature. > > At least for the time being, I think it should be left in Advanced. > Torley's video describing it points to the Advanced menu. After a > while, it might make sense to move it, but to change the default > condition and move the UI control at the same time seems a bit devious. > >> * Can someone (Mike?) add a bit more detail on the jira task to >> defend/review that the CPU impact is strictly capped. For example, >> what is the LOD behavior if there are 100 avatars all talking at the >> same time. We have LOD tricks for various rendering aspects of the >> system, do they correctly carry through? Does the CPU load of the >> feature vary by GPU? I think we need this level of documentation. > > Lip sync gets intensity indicators from voice chat the same way that > the green indicators do, so that is zero overhead. All it does is > change the morph weights for two localized morphs, very similar to eye > blinks. I have used the Fast Timers to try to measure any difference, > but see none. I never tried 100 avatars talking at once. The most I > ever heard speaking at once is about three. Yes, the LOD processing > stays exactly the same. The two new morphs were derived from existing > morphs. > >> * As to the question of whether to default it on or off, clearly it >> is a complex issue. I'd say lets default it on, and make sure it is >> easy to find the way to turn it off. For some use cases it is very >> cool, lending immersion and cueing as to speaker. For other cases >> you will want it off. We are still at the point where the 'uncanny >> valley' nature of the feature can make it unnerving, and that problem >> is unlikely to be easily solved soon in realtime with low CPU load. > > Hmmm. Faces that don't move while talking are unnerving to me, like > the commercials with the mannequins. Creepy. > >> As a final note, I'd say this is a good example of a tough topic >> where the right call is unclear and discussion and debate is >> appropriate. Also a good case of where if need be, I can just make a >> call and we move on and see what happens. Given that, why the >> rudeness I am seeing here? I don't see a need to be insulting to >> each other over this topic. Maybe I've missed some painful history >> here, but can't see how this is helping us move forward. I wouldn't >> work internally on projects at LL with colleagues that were overly >> rude, I don't see why it should be any different here! > > I haven't sensed any rudeness from others, just open discussion. If I > have been rude, I apologize. I did not intend to be. > > Mike > From dahliatrimble at gmail.com Sat May 2 16:28:32 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sat, 2 May 2009 16:28:32 -0700 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FCCC8C.9050502@lindenlab.com> References: <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FCCC8C.9050502@lindenlab.com> Message-ID: Somehow I think it should go into the voice chat tab of the preferences dialog along with the rest of the voice preferences. I have reason to believe that many voice users become familiar with that dialog. I've been selling a LSL based lip sync system for over a year now and it has a semi-transparent pair of lips that sit in the lower left corner of the viewer screen; clicking it brings up a menu of options that allows the user to turn it on or off or control various features, using the normal LSL based blue dialog menus. The dialog has built in descriptive text for each option and also can display a notecard with additional help text. I've had good feedback from my users about the menu system. The only reported trouble people have had with this system is when the voice system fails or if they have some misunderstanding about the gestures that must be installed to enable my HUD to function. On Sat, May 2, 2009 at 3:43 PM, Philip Rosedale wrote: > I think that right direction is to assume that the majority of usage would > favor having it on, but that it should be easy to turn off. > > Ron Blechner wrote: > > We are still at the point where the 'uncanny valley' nature of the feature > can make it unnerving, and that problem is unlikely to be easily solved soon > in realtime with low CPU load. > > > This is a really interesting point, as avatars I've seen in world > range from clear to the left of the uncanny valley, right through it, > to acceptably beyond it to the right. It's a large part of the reason > my avatar is still using default skin texture, wears sunglasses, and > has cartoony hair. There's no easy answer to this issue, as even as > technology changes, people will still have a range of different avatar > looks. My reasonable guess, based from my experience with lipsync in > other virtual world platforms and games, is that lipsync alone does > not cause much of an issue with the "freaky factor" as one may call > it. I believe facial expressions are a much trickier issue in regards > to the uncanny valley. (That said, I still think its absolutely > essential for the future of virtual worlds that facial expressions get > a move on.) > > I wonder, then, what sorts of evidence / research is needed? Maybe > this is a case where we all can just "do our homework" - there's > plenty of machinima on YouTube using Second Life and lipsync and > without it. And it's not difficult to find a variety of different > avatars - from cartoony to hyper-realistic - in which we can look at > how lipsync looks ourselves. Personally, I think doing this kind of > research will absolutely reinforce the idea of putting lipsync on by > default, but I'm certainly biased. :) ... I might also add that > non-human avatars have used Animation Overrider tools to replace the > typing and trigger prim-animations that move mouths. (Yes, I'm > referencing the furries!) > > I'd also be interested to hear anyone's first-hand experiences where > the lipsync is unnerving; Philip, have you had that experience > yourself? > > -Ron / Hiro > > CTO, Involve, Incwww.involve3d.com > SL: Hiro Pendragon > > > > > _______________________________________________ > 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/20090502/4c06a42e/attachment-0001.htm From moriz.gupte at gmail.com Sat May 2 17:21:46 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Sat, 2 May 2009 18:21:46 -0600 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FCCE02.4080500@lindenlab.com> References: <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <49FCCE02.4080500@lindenlab.com> Message-ID: I am thinking that this little issue we are discussing is a symptom of a systemic problem: how a UI is created and how it evolves. So it probably requires a new thread, but for continuity am keeping it here. I think we should try to find a generic way that if applied, might actually reduce the 'noise' inherent in UIs. What is this noise? This noise can manifest itself 'visually/cognitively'..crowded dialog boxes, too many nested levels of preferences (introduces search problems) etc.. So, how do we minimize this 'noise': A) We can avoiding the 'UI as reflection of underlying architecture' trap (and the flow of the conversation somewhat suggests that). As developers it is easier for us to use the 'developer' model of the application, assume the user has a similar model and let the architecture guide the UI. Yes for IDEs and such...rare cases, this approach can work. There are some UI researchers who have proposed 'UIs' not only as means to use/access an application but also to 'refine and modify' the core functionality of the application. We are not talking about this flavor of tailorability here. Here it would make sense for the underlying architecture to float up and be reflected at the level of the UI. We are more looking at 'consumer' perspective here, ie use of a product, pretty much like using an object in daily use e.g. a toothbrush. A lot of the UI interface noise in the SL client, ranging from camera controls, voice controls, could be reduced if we start eliminating anything preference or adjustments that actually can be traced to underlying architectural decisions which users with good reason do not care about. Keeping lipsync optional optional *when voice is already selected* is difficult to understand. This forced, unnatural decoupling of voice with lipsync is a result of our fixation on the developer model of the application. B) We can reduce UI noise by hiring a designer king e.g. Tufte (Data Visualization/GIS person) or Don Norman(UI researcher) who has a flair for those things (very rare... ) or let UI design decision be informed by 'use' data. The first option only works if you are lucky and land on a UI genius and his/her current state of mind etc.. etc.. (probability of success close to zero) I propose that we instrument (add some code that tracks UI manipulations) the client so that you get actual data about which features are being used, how often etc.. This of course should be client side only. We are also not talking about pushing data to LL every time this is done, but to have the data uploaded if / when the user want. I dont expect CPU footprint to be huge here..just writing a piece of data in a file is not expensive. This data can be used to inform decisions regarding which control points go where and whether certain control points are needed at all. We can use these data to visualize hot spots of UI use and so on. Just my opinion, of course. R On Sat, May 2, 2009 at 4:49 PM, Philip Rosedale wrote: > I'd like to see an implementation of turning on and off the lip sync > feature that can be user tested to demonstrate that a new user of SL > could be instructed to "Turn off the moving lips" and easy turn the > feature off within 30 seconds or so. > > I agree that a software developer, or someone who is already familiar > with the Advanced menus can do fine the way it is, but I'd like to move > with this project toward a viewer that is "generally appealing" - > meaning just as usable to a brand new user of Second Life as an existing > one or an experienced developer. > > Does this make sense? > > Philip > > Mike Monkowski wrote: > > Philip Rosedale wrote: > >> * We need a clear and discoverable place in the UI where this > >> feature can be enabled and disabled. Probably prefs. Can someone > >> take on that design and coding? Advanced-> isn't the right home for > >> this. We should do that work properly and well to complete this > >> feature. > > > > At least for the time being, I think it should be left in Advanced. > > Torley's video describing it points to the Advanced menu. After a > > while, it might make sense to move it, but to change the default > > condition and move the UI control at the same time seems a bit devious. > > > >> * Can someone (Mike?) add a bit more detail on the jira task to > >> defend/review that the CPU impact is strictly capped. For example, > >> what is the LOD behavior if there are 100 avatars all talking at the > >> same time. We have LOD tricks for various rendering aspects of the > >> system, do they correctly carry through? Does the CPU load of the > >> feature vary by GPU? I think we need this level of documentation. > > > > Lip sync gets intensity indicators from voice chat the same way that > > the green indicators do, so that is zero overhead. All it does is > > change the morph weights for two localized morphs, very similar to eye > > blinks. I have used the Fast Timers to try to measure any difference, > > but see none. I never tried 100 avatars talking at once. The most I > > ever heard speaking at once is about three. Yes, the LOD processing > > stays exactly the same. The two new morphs were derived from existing > > morphs. > > > >> * As to the question of whether to default it on or off, clearly it > >> is a complex issue. I'd say lets default it on, and make sure it is > >> easy to find the way to turn it off. For some use cases it is very > >> cool, lending immersion and cueing as to speaker. For other cases > >> you will want it off. We are still at the point where the 'uncanny > >> valley' nature of the feature can make it unnerving, and that problem > >> is unlikely to be easily solved soon in realtime with low CPU load. > > > > Hmmm. Faces that don't move while talking are unnerving to me, like > > the commercials with the mannequins. Creepy. > > > >> As a final note, I'd say this is a good example of a tough topic > >> where the right call is unclear and discussion and debate is > >> appropriate. Also a good case of where if need be, I can just make a > >> call and we move on and see what happens. Given that, why the > >> rudeness I am seeing here? I don't see a need to be insulting to > >> each other over this topic. Maybe I've missed some painful history > >> here, but can't see how this is helping us move forward. I wouldn't > >> work internally on projects at LL with colleagues that were overly > >> rude, I don't see why it should be any different here! > > > > I haven't sensed any rudeness from others, just open discussion. If I > > have been rude, I apologize. I did not intend to be. > > > > 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 > -- Rameshsharma Ramloll PhD Research Assistant Professor Idaho State University, PocatelloTel: 208-282-5333 Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2 , Blog: http://snipurl.com/3p5op , Play2Train: http://www.play2train.org ----- The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge- Stephen Hawking and many others who found light through the cracks of knowledge. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090502/bdef99e0/attachment.htm From melinda at superliminal.com Sat May 2 19:35:57 2009 From: melinda at superliminal.com (Melinda Green) Date: Sat, 02 May 2009 19:35:57 -0700 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <49FCCE02.4080500@lindenlab.com> Message-ID: <49FD030D.8010204@superliminal.com> I agree that usage data would provide an important missing piece to these discussions. I proposed a solution previously but not in this forum: Basically we could easily add a logging call to the base class of the component library that records a count for each human action on each UI element. The UI elements can be identified by a unique string consisting of their name plus their parent's name, etc. up the containment tree to the root view. The file would look something like this: COUNT PATH 26 Root/Communicate/Local Chat/Gestures 1 Root/Communicate/Local Chat/Show Muted Text 1 Root/Menus/Advanced/Character/Enable Lip Sync 1 Root/Menus/View/Look at Last Chatter 10 Root/Snapshot/Format ... This data should have everything we want to be able to make informed decisions about whether and how often various UI elements are actually used though maybe a 3rd column to include the last value. That data is especially useful when it can be combined with demographic data. On exit we just aggregate this list of paths & counts to the user's hard drive. This part shouldn't take someone more than an hour or so to implement. After that we just need to aggregate that data just like is currently done for crash reports. -Melinda Moriz Gupte wrote: > I am thinking that this little issue we are discussing is a symptom of > a systemic problem: how a UI is created and how it evolves. So it > probably requires a new thread, but for continuity am keeping it here. > > I think we should try to find a generic way that if applied, might > actually reduce the 'noise' inherent in UIs. What is this noise? This > noise can manifest itself 'visually/cognitively'..crowded dialog > boxes, too many nested levels of preferences (introduces search > problems) etc.. > So, how do we minimize this 'noise': > > A) We can avoiding the 'UI as reflection of underlying architecture' > trap (and the flow of the conversation somewhat suggests that). > As developers it is easier for us to use the 'developer' model of the > application, assume the user has a similar model and let the > architecture guide the UI. > Yes for IDEs and such...rare cases, this approach can work. There are > some UI researchers who have proposed 'UIs' not only as means to > use/access an application but also to 'refine and modify' the core > functionality of the application. We are not talking about this flavor > of tailorability here. Here it would make sense for the underlying > architecture to float up and be reflected at the level of the UI. We > are more looking at 'consumer' perspective here, ie use of a product, > pretty much like using an object in daily use e.g. a toothbrush. > > A lot of the UI interface noise in the SL client, ranging from camera > controls, voice controls, could be reduced if we start eliminating > anything preference or adjustments that actually can be traced to > underlying architectural decisions which users with good reason do not > care about. > Keeping lipsync optional optional *when voice is already selected* is > difficult to understand. This forced, unnatural decoupling of voice > with lipsync is a result of our fixation on the developer model of the > application. > > B) We can reduce UI noise by hiring a designer king e.g. Tufte (Data > Visualization/GIS person) or Don Norman(UI researcher) who has a flair > for those things (very rare... ) or let UI design decision be informed > by 'use' data. > The first option only works if you are lucky and land on a UI genius > and his/her current state of mind etc.. etc.. (probability of success > close to zero) > > I propose that we instrument (add some code that tracks UI > manipulations) the client so that you get actual data about which > features are being used, how often etc.. > This of course should be client side only. We are also not talking > about pushing data to LL every time this is done, but to have the data > uploaded if / when the user want. I dont expect CPU footprint to be > huge here..just writing a piece of data in a file is not expensive. > This data can be used to inform decisions regarding which control > points go where and whether certain control points are needed at all. > We can use these data to visualize hot spots of UI use and so on. > > Just my opinion, of course. > R > > On Sat, May 2, 2009 at 4:49 PM, Philip Rosedale > wrote: > > I'd like to see an implementation of turning on and off the lip sync > feature that can be user tested to demonstrate that a new user of SL > could be instructed to "Turn off the moving lips" and easy turn the > feature off within 30 seconds or so. > > I agree that a software developer, or someone who is already familiar > with the Advanced menus can do fine the way it is, but I'd like to > move > with this project toward a viewer that is "generally appealing" - > meaning just as usable to a brand new user of Second Life as an > existing > one or an experienced developer. > > Does this make sense? > > Philip > > Mike Monkowski wrote: > > Philip Rosedale wrote: > >> * We need a clear and discoverable place in the UI where this > >> feature can be enabled and disabled. Probably prefs. Can someone > >> take on that design and coding? Advanced-> isn't the right > home for > >> this. We should do that work properly and well to complete this > >> feature. > > > > At least for the time being, I think it should be left in Advanced. > > Torley's video describing it points to the Advanced menu. After a > > while, it might make sense to move it, but to change the default > > condition and move the UI control at the same time seems a bit > devious. > > > >> * Can someone (Mike?) add a bit more detail on the jira task to > >> defend/review that the CPU impact is strictly capped. For example, > >> what is the LOD behavior if there are 100 avatars all talking > at the > >> same time. We have LOD tricks for various rendering aspects of the > >> system, do they correctly carry through? Does the CPU load of the > >> feature vary by GPU? I think we need this level of documentation. > > > > Lip sync gets intensity indicators from voice chat the same way that > > the green indicators do, so that is zero overhead. All it does is > > change the morph weights for two localized morphs, very similar > to eye > > blinks. I have used the Fast Timers to try to measure any > difference, > > but see none. I never tried 100 avatars talking at once. The > most I > > ever heard speaking at once is about three. Yes, the LOD processing > > stays exactly the same. The two new morphs were derived from > existing > > morphs. > > > >> * As to the question of whether to default it on or off, clearly it > >> is a complex issue. I'd say lets default it on, and make sure > it is > >> easy to find the way to turn it off. For some use cases it is very > >> cool, lending immersion and cueing as to speaker. For other cases > >> you will want it off. We are still at the point where the 'uncanny > >> valley' nature of the feature can make it unnerving, and that > problem > >> is unlikely to be easily solved soon in realtime with low CPU load. > > > > Hmmm. Faces that don't move while talking are unnerving to me, like > > the commercials with the mannequins. Creepy. > > > >> As a final note, I'd say this is a good example of a tough topic > >> where the right call is unclear and discussion and debate is > >> appropriate. Also a good case of where if need be, I can just > make a > >> call and we move on and see what happens. Given that, why the > >> rudeness I am seeing here? I don't see a need to be insulting to > >> each other over this topic. Maybe I've missed some painful history > >> here, but can't see how this is helping us move forward. I > wouldn't > >> work internally on projects at LL with colleagues that were overly > >> rude, I don't see why it should be any different here! > > > > I haven't sensed any rudeness from others, just open discussion. > If I > > have been rude, I apologize. I did not intend to be. > > > > Mike > From stickman at gmail.com Sun May 3 01:29:45 2009 From: stickman at gmail.com (Stickman) Date: Sun, 3 May 2009 01:29:45 -0700 Subject: [sldev] Anyone from the time of Dynamic Reflections still here? In-Reply-To: <49FC2D87.3020602@Gmail.com> References: <49FC2D87.3020602@Gmail.com> Message-ID: > I would like to know what happened exactly, at first it worked perfectly > for me, then it stopped being supported cause it was crashing some > people, then it started working worse and worse for me and eventually I > couldn't even find it on the client at all. Is any Linden around that > was around back when it all took place and knows the details of what > happened? I remember those! They were fun to play with. There were some issues if you went into mouselook with "show avatar in mouselook" clicked, but they otherwise seemed to work well. I wasn't paying much attention at the time. I believe they were in an RC. But I don't think they ever made it out, did they? I have a number of screenshots in my inventory about those... Here we go: http://stickman.mach5.org/temp/sl-reflect.jpg Is that what we're talking about? -Stickman From tigrospottystripes at gmail.com Sun May 3 01:46:12 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 03 May 2009 05:46:12 -0300 Subject: [sldev] Anyone from the time of Dynamic Reflections still here? In-Reply-To: References: <49FC2D87.3020602@Gmail.com> Message-ID: <49FD59D4.5000808@Gmail.com> Stickman escreveu: >> I would like to know what happened exactly, at first it worked perfectly >> for me, then it stopped being supported cause it was crashing some >> people, then it started working worse and worse for me and eventually I >> couldn't even find it on the client at all. Is any Linden around that >> was around back when it all took place and knows the details of what >> happened? >> > > I remember those! They were fun to play with. > > There were some issues if you went into mouselook with "show avatar in > mouselook" clicked, but they otherwise seemed to work well. > > I wasn't paying much attention at the time. I believe they were in an > RC. But I don't think they ever made it out, did they? > > I have a number of screenshots in my inventory about those... Here we go: > http://stickman.mach5.org/temp/sl-reflect.jpg > > Is that what we're talking about? > > -Stickman > > I think so, but I can't tell if those were already the versions that started misbehaving, I got a couple shots from the good version (and perhaps a one or two from when it was bad, I don't remember) on my galery at ProfilesLive ( http://www.profileslive.com/profilepictures.asp?id=4766 ) . I remember for some versions it reflected well, but the reflection map position snapped to coordinates several meters apart and somtimes it would reflect a point very far in the sim, there was also a time when the reflections where fuzzy no matter what resolution you set them to be, then the reflection was only updated the moment you turned Dynamic Reflections on and then stayed frozen, after that I think it would show some random scrapings of the video memory, and when Windlight arived, or perhaps some time later, it started messing up the screen if used in combination with Athmospheric Shaders, and eventually it was gone completly. I think it was a First Look and not a RC client, at least at first, but I have a slightly fuzzy memory of a debug setting for it reaching the main client even after the option in the Advanced (I think then it was called Client or perhaps Debug, I'm not sure) menu was gone, but that too was removed several versions later. From tigrospottystripes at gmail.com Sun May 3 01:53:08 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 03 May 2009 05:53:08 -0300 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FD030D.8010204@superliminal.com> References: <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <49FCCE02.4080500@lindenlab.com> <49FD030D.8010204@superliminal.com> Message-ID: <49FD5B74.1000808@Gmail.com> How about having an "advanced" version of the preferences window, with options that are advanced for the regular users, but already past beta therefore not belonging on the Advanced menu, with a checkbox on the general tab of the preferences window to hide or show the advanced settings ? From melinda at superliminal.com Sun May 3 08:09:38 2009 From: melinda at superliminal.com (Melinda Green) Date: Sun, 03 May 2009 08:09:38 -0700 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FD5B74.1000808@Gmail.com> References: <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <49FCCE02.4080500@lindenlab.com> <49FD030D.8010204@superliminal.com> <49FD5B74.1000808@Gmail.com> Message-ID: <49FDB3B2.5000603@superliminal.com> An advanced preferences floater would not be much different from all the "Advanced" buttons we already have in the existing one but less standard and harder to find something you're looking for. I prefer working hard to find good organizations of all Preferences controls considered to have value and not worrying so much about the number of them. When in doubt, moving a control to or from the Advanced menu is a reasonable solution. -Melinda Tigro Spottystripes wrote: > How about having an "advanced" version of the preferences window, with > options that are advanced for the regular users, but already past beta > therefore not belonging on the Advanced menu, with a checkbox on the > general tab of the preferences window to hide or show the advanced > settings ? > > From gigstaggart at gmail.com Sun May 3 11:51:36 2009 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun, 03 May 2009 14:51:36 -0400 Subject: [sldev] [META] indentation fixes/changes and merging In-Reply-To: References: <49FAF889.2040200@boroon.dasgupta.ch> <49FB260C.7010408@boroon.dasgupta.ch> Message-ID: <49FDE7B8.7030300@gmail.com> Soft wrote: > already poorly structured. So that underscores the importance of > cleaning up code when touching the code for other purposes. Maybe this This is a mixed message. I've had Lindens in the past tell me that they don't like it when I include formatting fixes in patches because it obscures the functional change. -Jason From secret.argent at gmail.com Sun May 3 12:24:10 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 3 May 2009 14:24:10 -0500 Subject: [sldev] Anyone from the time of Dynamic Reflections still here? In-Reply-To: <49FD59D4.5000808@Gmail.com> References: <49FC2D87.3020602@Gmail.com> <49FD59D4.5000808@Gmail.com> Message-ID: <0321E59C-6013-4243-9F7B-28624ABB4EFB@gmail.com> I have several nice shots from this period in my Snapzilla album at http://www.sluniverse.com/pics/ProfilePage.aspx?Name=Argent%20Stonecutter From stickman at gmail.com Sun May 3 18:27:31 2009 From: stickman at gmail.com (Stickman) Date: Sun, 3 May 2009 18:27:31 -0700 Subject: [sldev] Anyone from the time of Dynamic Reflections still here? In-Reply-To: <49FC2D87.3020602@Gmail.com> References: <49FC2D87.3020602@Gmail.com> Message-ID: > couldn't even find it on the client at all. Is any Linden around that > was around back when it all took place and knows the details of what > happened? So here's my guess. You're gonna need to visit a Linden's office hours. Even if a specific Linden can't answer your question, they may be able to direct you towards someone who can. From ron at involve3d.com Sun May 3 20:17:58 2009 From: ron at involve3d.com (Ron Blechner) Date: Sun, 3 May 2009 23:17:58 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FDB3B2.5000603@superliminal.com> References: <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <49FCCE02.4080500@lindenlab.com> <49FD030D.8010204@superliminal.com> <49FD5B74.1000808@Gmail.com> <49FDB3B2.5000603@superliminal.com> Message-ID: I have always thought that good preferences organization is about good grouping of similar topics with further drill-down pages as you get to nitty-grittier options. For example, I liked the way Linden Lab handled the Advanced Graphics tab, where you need to click a box to open up the specific settings for draw distance, object/tree/etc detail, etc. I think that serves as a good example of how lots-of-feature-options can be put intelligently into a menu. Additionally, I think Linden Lab can consider the +/- expand practice that is commonplace among software with lots of preferences, where you have broader top-level topics that expand into sub-topics. -Ron -- Ron Blechner Chief Technology Officer Involve, Inc www.involve3d.com SL: Hiro Pendragon On Sun, May 3, 2009 at 11:09 AM, Melinda Green wrote: > An advanced preferences floater would not be much different from all the > "Advanced" buttons we already have in the existing one but less standard > and harder to find something you're looking for. I prefer working hard > to find good organizations of all Preferences controls considered to > have value and not worrying so much about the number of them. When in > doubt, moving a control to or from the Advanced menu is a reasonable > solution. > > -Melinda > > Tigro Spottystripes wrote: >> How about having an "advanced" version of the preferences window, with >> options that are advanced for the regular users, but already past beta >> therefore not belonging on the Advanced menu, with a checkbox on the >> general tab of the preferences window to hide or show the advanced >> settings ? >> >> > _______________________________________________ > 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 Mon May 4 09:03:41 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon, 04 May 2009 12:03:41 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49fcc3c5.27ba720a.128c.ffffc9ac@mx.google.com> References: <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <493033a70905020555p601477f5t810c7417cc95b6b0@mail.gmail.com> <49fcc3c5.27ba720a.128c.ffffc9ac@mx.google.com> Message-ID: <49FF11DD.4040304@watson.ibm.com> Andromeda Quonset wrote: > Jumping in here on this conversation...... > > I am finding it incredible that a new feature would be suggested, be > enabled by default, and then have it decided to not have a way of > disabling the feature in preferences because someone thinks preferences > menu is so crowded. If the lip sync "feature" MUST be added, to add it > without some way of turning it off is unconscionable. If the > preferences menu is not the place to disable it, then where do you > proposed disabling it? Use a command line argument, perhaps? Or maybe > I have to place a secret text file in some directory you specify that > contains a keyword like NO_LIP_SYNC ? Maybe it can be linked to a new > ctrl-alt-shift-function key combination? Or do you have a different idea? The lip sync feature doesn't have to be added. It's already there. But many people (like yourself) don't know it exists because it is disabled by default and must be enabled using the "Advanced" menu, which again many people don't know exists, because it too is disabled by default and can only be enabled with a ctrl-alt-d key combination. Mike From monkowsk at watson.ibm.com Mon May 4 09:09:05 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon, 04 May 2009 12:09:05 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> Message-ID: <49FF1321.3020106@watson.ibm.com> Gordon Wendt wrote: > No no and no, if it's optional then by all means hide it in advanced but > if you have it switched on by default you have to have an easy way to > turn it on and off which means the preferences, otherwise don't turn it > on by default. I think you're right. If we're going to have an option to disable it, it should be in Preferences. I forgot how long it took me to find the "Advanced" menu (called "Client" back then). It may be OK to leave the option in Advanced as well for a short period, since people who have already used it expect it there. Mike Mm Alder From josh at lindenlab.com Mon May 4 09:26:33 2009 From: josh at lindenlab.com (Joshua Bell) Date: Mon, 04 May 2009 09:26:33 -0700 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <5A61915E6A00424F831DD423DBC574BC@neptune.priv> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com><493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com><49F867E1.6040805@watson.ibm.com><784490.3996.qm@web59104.mail.re1.yahoo.com><49F8AFAD.3040007@watson.ibm.com><1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com><49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com><493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> Message-ID: <49FF1739.9060203@lindenlab.com> Just to throw out my heuristic here: "A feature that's not enabled by default might as well not exist" Caveats: * Features that auto-enable based on some action or quality (e.g. video card capabilities, etC) don't count * Diagnostic/experimental features (e.g. debug consoles) don't count * Features that serve an uncommon but critical purpose (e.g. "purge my cache", "override system locale", etc) don't count, assuming they can be found by searching documentation. ... and so forth. The counter-caveat is that none of these can detract from overall usability. Corollary #1: You're adding features that are enabled by default Corollary #2: The ability to disable a feature is, itself, a feature, and therefore must be justified by the above heuristic! So I'd ask folks on this thread: (1) Is the lip-sync feature something that the majority of users will find a beneficial addition to their Second Life experience, or attract new users to the system? If so, then make it enabled by default! (2) Is the ability to disable lip-sync something that a significant number of users will need? Only if this is critical should this feature be added. IMHO, the discussion on this list has not provided sufficient evidence that adding the "disable lip-sync" feature is warranted. (I'm not saying it isn't warranted, just that I haven't seen the evidence. It's also unclear that a "don't show lip-sync for anyone I'm looking at" is the desired anti-feature, vs. "don't show anyone lip-sync for my mouthless avatar".) FWIW, I'd vote for shoving a checkbox in the Voice Prefs tab, because it's not that cluttered and once a user has fallen into Preferences we've lost the "keep it simple and discoverable" game anyway. :( Like any UI, Preferences will continue to evolve with periodic reorganizations of the content. No app (that I'm aware of) that caters to non-engineers has ever had a stable preferences UI over several iterations. From missannotoole at yahoo.com Mon May 4 09:34:27 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Mon, 4 May 2009 09:34:27 -0700 (PDT) Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FF1739.9060203@lindenlab.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com><493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com><49F867E1.6040805@watson.ibm.com><784490.3996.qm@web59104.mail.re1.yahoo.com><49F8AFAD.3040007@watson.ibm.com><1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com><49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com><493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> Message-ID: <624016.21842.qm@web59105.mail.re1.yahoo.com> RE: "lip sync" capabilities in Second Life Let me know when a deaf person can read the avatar lips and understand what is being said through the microphone and I will fully support it not only being on by default but no option to turn it off. Until then it looks like a bad kung fu movie dubbing job. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090504/1ced452b/attachment.htm From brad at lindenlab.com Mon May 4 09:49:30 2009 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Mon, 04 May 2009 12:49:30 -0400 Subject: [sldev] Anyone from the time of Dynamic Reflections still here? In-Reply-To: <49FD59D4.5000808@Gmail.com> References: <49FC2D87.3020602@Gmail.com> <49FD59D4.5000808@Gmail.com> Message-ID: <49FF1C9A.5030000@lindenlab.com> Tigro Spottystripes wrote: > Stickman escreveu: > >>> I would like to know what happened exactly, at first it worked perfectly >>> for me, then it stopped being supported cause it was crashing some >>> people, then it started working worse and worse for me and eventually I >>> couldn't even find it on the client at all. Is any Linden around that >>> was around back when it all took place and knows the details of what >>> happened? >>> >>> >> I remember those! They were fun to play with. >> >> There were some issues if you went into mouselook with "show avatar in >> mouselook" clicked, but they otherwise seemed to work well. >> >> I wasn't paying much attention at the time. I believe they were in an >> RC. But I don't think they ever made it out, did they? >> >> I have a number of screenshots in my inventory about those... Here we go: >> http://stickman.mach5.org/temp/sl-reflect.jpg >> >> Is that what we're talking about? >> >> -Stickman >> >> >> > > I think so, but I can't tell if those were already the versions that > started misbehaving, I got a couple shots from the good version (and > perhaps a one or two from when it was bad, I don't remember) on my > galery at ProfilesLive ( > http://www.profileslive.com/profilepictures.asp?id=4766 ) . I remember > for some versions it reflected well, but the reflection map position > snapped to coordinates several meters apart and somtimes it would > reflect a point very far in the sim, there was also a time when the > reflections where fuzzy no matter what resolution you set them to be, > then the reflection was only updated the moment you turned Dynamic > Reflections on and then stayed frozen, after that I think it would show > some random scrapings of the video memory, and when Windlight arived, or > perhaps some time later, it started messing up the screen if used in > combination with Athmospheric Shaders, and eventually it was gone completly. > > I think it was a First Look and not a RC client, at least at first, but > I have a slightly fuzzy memory of a debug setting for it reaching the > main client even after the option in the Advanced (I think then it was > called Client or perhaps Debug, I'm not sure) menu was gone, but that > too was removed several versions later. > Well, I think I remember some discussions about whether to maintain dynamic reflections when we began integrating Windlight, and the decision was 'no'. At that point, I think it was a debug setting in the release client, but the feature had been stagnant for some time. If I recall correctly, the reasons for leaving it unmaintained were that the existing implementation was rather unscalable (in terms of video memory usage and extra rendering passes) and could "never" have been brought up to releasable quality. Work on Windlight integration broke it, as the same code was now being used for the Windlight water, but not being maintained for compatibility with existing dynamic reflections. The debug setting was removed shortly thereafter. I may be recalling some things incorrectly here, but I think I got the basics right. -Brad From monkowsk at watson.ibm.com Mon May 4 10:08:59 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon, 04 May 2009 13:08:59 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <624016.21842.qm@web59105.mail.re1.yahoo.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com><493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com><49F867E1.6040805@watson.ibm.com><784490.3996.qm@web59104.mail.re1.yahoo.com><49F8AFAD.3040007@watson.ibm.com><1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com><49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com><493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <624016.21842.qm@web59105.mail.re1.yahoo.com> Message-ID: <49FF212B.2050604@watson.ibm.com> Ann Otoole wrote: > RE: "lip sync" capabilities in Second Life > > Let me know when a deaf person can read the avatar lips and understand > what is being said through the microphone and I will fully support it > not only being on by default but no option to turn it off. Until then it > looks like a bad kung fu movie dubbing job. The technology exists to make lip sync good enough for lipreading, but until Vivox opens the source for SLVoice, giving access to the audio stream, this "bad kung fu movie dubbing" is all that is possible. Also, lipreading-quality lip sync would require real CPU cycles. It would, hovever, be possible to make it more realistic with very little CPU resource. Mike From monkowsk at watson.ibm.com Mon May 4 10:51:05 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon, 04 May 2009 13:51:05 -0400 Subject: [sldev] Open Source Meeting, 2PM PDT, Hippotropolis In-Reply-To: <49FB7D49.5080305@watson.ibm.com> References: <3B7F46F8-2F96-49B9-B62F-879D3BBD3B34@lindenlab.com> <49F9CA9A.2000103@watson.ibm.com> <49FA398A.5090105@watson.ibm.com> <49FB7D49.5080305@watson.ibm.com> Message-ID: <49FF2B09.8050104@watson.ibm.com> OK, I think I've got everyting from Q's page into mine. Everybody, don't be shy about hacking away at the page I wrote. That's what it's there for. Mike Mm Alder Mike Monkowski wrote: > Rats! I just finished filling it in myself. I'll have a look at > merging the two. > > Mike > > > Kent Quirk (Q Linden) wrote: > >>Thanks for the outline, Mike. >> >>I've created a version of it here from comments Merov has made plus a >>few of my own: >> >>https://wiki.secondlife.com/wiki/SLDev_Open_Source_Viewer >> >>I'd encourage Lindens -- especially Merov and Philip -- to expand on it. >> >> Q >> >>On Apr 30, 2009, at 7:51 PM, Mike Monkowski wrote: >> >> >>>As I warned :-) at the meeting today, I'm making up documentation for >>>this new Open Source Viewer process. You can see the work in >>>progress at >>>http://wiki.secondlife.com/wiki/User:Mm_Alder/SLDev_Open_Source_Viewer >>> Feel free to edit whatever you like. I'm only doing this because no >>>one else would. :-) >>> >>>Mike From moriz.gupte at gmail.com Mon May 4 11:41:08 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Mon, 4 May 2009 12:41:08 -0600 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FF212B.2050604@watson.ibm.com> References: <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <624016.21842.qm@web59105.mail.re1.yahoo.com> <49FF212B.2050604@watson.ibm.com> Message-ID: Hello Ann, I think it's fair to understand this to be work in progress, I imagine most folks will not expect high fidelity in the begining (have no data to back this). In my case and that of my audience, they serve more as a mediating cue as discussed earlier (this cue is nevertheless weakened by the fact that the 3rd person view is the only 'usable' view in SL and when we stand the lip motions are sometimes hard to catch). However, when we sit around a table those cues are terribly effective. I run meetings every week in SL. In the begining I had to implement a tiny HUD (worn on top) with 5 basic functions (Wave, Yes, No, Clap, Away). People used to wave to manage turn taking. With lipsync, they dont need to wave but feel more comfortable interrupting. So even at this low level of fidelity, it helps. What about the green indicator? well they don't seems as effective...we do use the green indicators during voice troubleshooting...but during conversations they are a visual encumbrance, obtrusive almost. At close range...around a table, they are meaningless...takes some brain processing to find which white dot belongs to whom. This destroys immersion, focuse moved from face to dots above head. I am tempted to discuss about 'design of notifications here, and the need to fine tune their degree of obtrusiveness) but that would be labouring the point. Having spent some time designing for autistic children, am aware of face processing training strategies involving games that start in the beginning stages with facial cartoon expressions (just animated eye brows for .e.g.) before progressing to real human expressions. So this fidelity argument can have many strands.... Keeping in mind the deaf might appear an inclusive approach but not necessarily. On a different note, Has '"bad kung fu movie dubbing" evolved into an artistic medium, just wondering. For those who have time for some levity http://tinyurl.com/ckrey5 And more generally, at what point does the 'fidelity argument' 'uncanny valley' arguments become relevant? Given the kind of CPU load that we are expecting to achieve our fidelity goals, I cannot see a high fidelity SL in the near year or the year after that (unless a carmack is born somewhere...and finds a way to squeeze something out of existing hardware). Alternative strategies: Would a mashup of video conferencing technology and SL be useful without destroying the immersive nature of SL? I hope to see a video conferencing technology company partner with SL in the same way that vivox did. Ramesh ( I think I have to use my rl name..SL has fragmented my identity...too many alts...this is not entirely bad btw) On Mon, May 4, 2009 at 11:08 AM, Mike Monkowski wrote: > Ann Otoole wrote: > > RE: "lip sync" capabilities in Second Life > > > > Let me know when a deaf person can read the avatar lips and understand > > what is being said through the microphone and I will fully support it > > not only being on by default but no option to turn it off. Until then it > > looks like a bad kung fu movie dubbing job. > > The technology exists to make lip sync good enough for lipreading, but > until Vivox opens the source for SLVoice, giving access to the audio > stream, this "bad kung fu movie dubbing" is all that is possible. Also, > lipreading-quality lip sync would require real CPU cycles. It would, > hovever, be possible to make it more realistic with very little CPU > resource. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090504/5a7b8663/attachment.htm From aimee.trescothick at gmail.com Mon May 4 17:57:30 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Tue, 5 May 2009 01:57:30 +0100 Subject: [sldev] Review request: VWR-12696 Bug fix (Blurry mini-map) Message-ID: <367CD852-3AB7-4C34-9452-56B3C5D55734@gmail.com> Hi, Would another committer mind running an eye over and testing my 3- liner fix for http://jira.secondlife.com/browse/VWR-12696 so that I can commit it? Aimee. From merov at lindenlab.com Mon May 4 18:26:05 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Mon, 4 May 2009 18:26:05 -0700 Subject: [sldev] http-texture build failing on Linux Message-ID: Hi Aimee, The projects/2009/http-texture build is failing on Linux with: cc1plus: warnings being treated as errors /var/opt/parabuild/checkout/L-sweeper/linden/indra/newview/ llpreviewtexture.cpp: In member function 'void LLPreviewTexture::updateDimensions()': /var/opt/parabuild/checkout/L-sweeper/linden/indra/newview/ llpreviewtexture.cpp:431: warning: converting to 'S32' from 'F32' make[3]: *** [newview/CMakeFiles/secondlife-bin.dir/ llpreviewtexture.o] Error 1 It seems to be caused by your change as part of: r2215 | aimee.trescothick | 2009-05-02 10:30:43 -0700 (Sat, 02 May 2009) | 2 lines VWR-8008: Drop-down to select preset aspect ratios in texture preview floaters Would you mind to check this out? Thanks! Cheers, - Merov From aimee.trescothick at gmail.com Mon May 4 18:59:56 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Tue, 5 May 2009 02:59:56 +0100 Subject: [sldev] http-texture build failing on Linux In-Reply-To: References: Message-ID: <901E7CAB-F00E-4EE8-8D40-1F783AEF085C@gmail.com> Rob pinged me about this on IRC a few minutes ago, I've just committed a fix. Has alerted me though that there should probably also be some more bounds checking added in case people manually enter silly aspect ratios, I'll follow that up separately. Aimee. On 5 May 2009, at 02:26, Philippe Bossut (Merov Linden) wrote: > Hi Aimee, > > The projects/2009/http-texture build is failing on Linux with: > > cc1plus: warnings being treated as errors > /var/opt/parabuild/checkout/L-sweeper/linden/indra/newview/ > llpreviewtexture.cpp: In member function 'void > LLPreviewTexture::updateDimensions()': > /var/opt/parabuild/checkout/L-sweeper/linden/indra/newview/ > llpreviewtexture.cpp:431: warning: converting to 'S32' from 'F32' > make[3]: *** [newview/CMakeFiles/secondlife-bin.dir/ > llpreviewtexture.o] Error 1 > > It seems to be caused by your change as part of: > r2215 | aimee.trescothick | 2009-05-02 10:30:43 -0700 (Sat, 02 May > 2009) | 2 lines > VWR-8008: Drop-down to select preset aspect ratios in texture preview > floaters > > Would you mind to check this out? > > Thanks! > > Cheers, > - Merov > _______________________________________________ > 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 mrfrans at gmail.com Mon May 4 19:24:45 2009 From: mrfrans at gmail.com (Frans) Date: Tue, 5 May 2009 04:24:45 +0200 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <624016.21842.qm@web59105.mail.re1.yahoo.com> <49FF212B.2050604@watson.ibm.com> Message-ID: <7765f2c60905041924u3f398373ie58ef170cfcacf76@mail.gmail.com> To keep it short. I agree with having lip sync on by default and having a check box for it in the voice preferences tab. However good or bad lib sync may look, imho new users expect the lips to move when using voice. That's what they take with them from RL. I think Melinda Green has a great idea to collect usage data on the user interface, it would give a lot of information on how it is being used. I would expand it a bit and save all interactions (with the UI) sequential. That way we can also learn which actions are taken after each other, if it turn out button A and Z are always pressed after one another we could create button AZ and simplify. We might want to start a new chain to discuss this. -- Jeroen Frans Executive Director TheVesuviusGroup.com SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090505/bc782aa2/attachment.htm From jamey at beau.org Mon May 4 20:12:02 2009 From: jamey at beau.org (Jamey Fletcher) Date: Mon, 04 May 2009 22:12:02 -0500 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FF1739.9060203@lindenlab.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com><493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com><49F867E1.6040805@watson.ibm.com><784490.3996.qm@web59104.mail.re1.yahoo.com><49F8AFAD.3040007@watson.ibm.com><1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com><49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com><493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> Message-ID: <49FFAE82.6030409@beau.org> Joshua Bell wrote: > Only if this is critical should this feature be added. IMHO, the > discussion on this list has not provided sufficient evidence that adding > the "disable lip-sync" feature is warranted. (I'm not saying it isn't > warranted, just that I haven't seen the evidence. It's also unclear that > a "don't show lip-sync for anyone I'm looking at" is the desired > anti-feature, vs. "don't show anyone lip-sync for my mouthless avatar".) > FWIW, I'd vote for shoving a checkbox in the Voice Prefs tab, because > it's not that cluttered and once a user has fallen into Preferences > we've lost the "keep it simple and discoverable" game anyway. :( Like > any UI, Preferences will continue to evolve with periodic > reorganizations of the content. No app (that I'm aware of) that caters > to non-engineers has ever had a stable preferences UI over several > iterations. Well, for preferences UI - I rather like xine's. However - What would be sufficient evidence that adding the "disable lip-sync" feature is warranted? A vote of users? I'll add mine in here. A vote on the JIRA? I need to go look at that - but the JIRA only allows votes for, not against. That's why the Mesh Import topic has two JIRA entries. (I voted against, wanting improved tools to manipulate content *in world*, rather than taking yet one more step towards pushing the newbie *out* of content creation. It's bad enough that you're stuck working out of the world for texture and audio work - once meshes become importable, you can kiss prims goodbye completely. A proposal for the Linden feature-putting-in team. You know that poll that pops up from time to time on log in? How about this - any new feature suggestion gets put into those polls. A log of which AV is asked (as in who logs in right afterwards) is maintained, and AVs only get counted once (maybe by IP, instead of who logs in right afterwards?). After 500, or a 1000 responses to that feature are gathered, the summarized response (x said yes, y said no, z didn't answer when presented the option) would be posted somewhere - not before, to help limit ballot stuffing. This would give the team basic feedback to decide whether to take the next step: actually posting information on what the feature/decision is all about, and opening forum discussions on it. *ONLY* after this takes place, does anyone bother actually coding it and starting integrating it into the RCs. That might help silence some of the complaints, such as the big foo-rah about openspace/homestead SIMs, or the bug-a-boo about the Adults Only areas (which topic I'd *REALLY* like to see some data on how much demand for it there really was... 1 request each from 50,000 AVs, or 5000 requests from 10 AVs?) Seriously, though - I don't mind a lot of options in the Preferences - but I do think it would make it easier to manage for most people if there were levels - Beginner, Intermediate, Master, "I know more about SL than the Lindens Do"... The higher you pick, the more options become available. At the highest level, the debug options from the Advanced menu (and most of the Advanced menu, in fact) becomes available in appropriate sections. Maybe make them tabs across the top, of the tabs along the side windows. This makes them fairly discoverable, while leaving the messy ones out of the way of the people who don't want to play with them. From tigrospottystripes at gmail.com Mon May 4 20:23:59 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 05 May 2009 00:23:59 -0300 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FFAE82.6030409@beau.org> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com><493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com><49F867E1.6040805@watson.ibm.com><784490.3996.qm@web59104.mail.re1.yahoo.com><49F8AFAD.3040007@watson.ibm.com><1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com><49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com><493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> Message-ID: <49FFB14F.3070102@Gmail.com> One of the things about the debug options is that it doesn't got interface for each thing, it is a combo box to choose the option and then an appropriate type of input field deppendng on the data type and such, basicly it requires much less work to add a new option (I imagine) . I like your idea of having everything in the preferences screen a lot, but I think that even if the advanced menu gets moved completly, there would still be need of having the Debug Options window. I think perhaps like I suggested before, the preferences window would be for things that are past beta, though leaving things that are actions instead of preferences in the advanced menu, and perhaps add a "Beta" menu for both commands and settings that are still in beta stage, leaving the Advanced menu for advanced commands, and the preferences window for settings, with a gradation like you suggested, perhaps the advanced menu would show when the level in the preferences window was one before the bigger one, and the Beta menu for the biggest level that can be set. Jamey Fletcher escreveu: > Joshua Bell wrote: > > >> Only if this is critical should this feature be added. IMHO, the >> discussion on this list has not provided sufficient evidence that adding >> the "disable lip-sync" feature is warranted. (I'm not saying it isn't >> warranted, just that I haven't seen the evidence. It's also unclear that >> a "don't show lip-sync for anyone I'm looking at" is the desired >> anti-feature, vs. "don't show anyone lip-sync for my mouthless avatar".) >> > > >> FWIW, I'd vote for shoving a checkbox in the Voice Prefs tab, because >> it's not that cluttered and once a user has fallen into Preferences >> we've lost the "keep it simple and discoverable" game anyway. :( Like >> any UI, Preferences will continue to evolve with periodic >> reorganizations of the content. No app (that I'm aware of) that caters >> to non-engineers has ever had a stable preferences UI over several >> iterations. >> > > > Well, for preferences UI - I rather like xine's. > > However - What would be sufficient evidence that adding the "disable > lip-sync" feature is warranted? A vote of users? I'll add mine in > here. A vote on the JIRA? I need to go look at that - but the JIRA > only allows votes for, not against. That's why the Mesh Import topic > has two JIRA entries. (I voted against, wanting improved tools to > manipulate content *in world*, rather than taking yet one more step > towards pushing the newbie *out* of content creation. It's bad enough > that you're stuck working out of the world for texture and audio work - > once meshes become importable, you can kiss prims goodbye completely. > > A proposal for the Linden feature-putting-in team. You know that poll > that pops up from time to time on log in? How about this - any new > feature suggestion gets put into those polls. A log of which AV is > asked (as in who logs in right afterwards) is maintained, and AVs only > get counted once (maybe by IP, instead of who logs in right > afterwards?). After 500, or a 1000 responses to that feature are > gathered, the summarized response (x said yes, y said no, z didn't > answer when presented the option) would be posted somewhere - not > before, to help limit ballot stuffing. This would give the team basic > feedback to decide whether to take the next step: actually posting > information on what the feature/decision is all about, and opening forum > discussions on it. *ONLY* after this takes place, does anyone bother > actually coding it and starting integrating it into the RCs. That might > help silence some of the complaints, such as the big foo-rah about > openspace/homestead SIMs, or the bug-a-boo about the Adults Only areas > (which topic I'd *REALLY* like to see some data on how much demand for > it there really was... 1 request each from 50,000 AVs, or 5000 requests > from 10 AVs?) > > Seriously, though - I don't mind a lot of options in the Preferences - > but I do think it would make it easier to manage for most people if > there were levels - Beginner, Intermediate, Master, "I know more about > SL than the Lindens Do"... The higher you pick, the more options become > available. At the highest level, the debug options from the Advanced > menu (and most of the Advanced menu, in fact) becomes available in > appropriate sections. Maybe make them tabs across the top, of the tabs > along the side windows. This makes them fairly discoverable, while > leaving the messy ones out of the way of the people who don't want to > play with them. > _______________________________________________ > 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 Mon May 4 21:33:08 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Mon, 4 May 2009 21:33:08 -0700 Subject: [sldev] http-texture build failing on Linux In-Reply-To: <901E7CAB-F00E-4EE8-8D40-1F783AEF085C@gmail.com> References: <901E7CAB-F00E-4EE8-8D40-1F783AEF085C@gmail.com> Message-ID: <0265B34C-B449-46C8-A6F6-283BD32053A2@lindenlab.com> Thanks for the quick fix Aimee! You rock! :) Cheers, - Merov On May 4, 2009, at 6:59 PM, Aimee Trescothick wrote: > Rob pinged me about this on IRC a few minutes ago, I've just > committed a fix. > > Has alerted me though that there should probably also be some more > bounds checking added in case people manually enter silly aspect > ratios, I'll follow that up separately. > > Aimee. > > On 5 May 2009, at 02:26, Philippe Bossut (Merov Linden) wrote: > >> Hi Aimee, >> >> The projects/2009/http-texture build is failing on Linux with: >> >> cc1plus: warnings being treated as errors >> /var/opt/parabuild/checkout/L-sweeper/linden/indra/newview/ >> llpreviewtexture.cpp: In member function 'void >> LLPreviewTexture::updateDimensions()': >> /var/opt/parabuild/checkout/L-sweeper/linden/indra/newview/ >> llpreviewtexture.cpp:431: warning: converting to 'S32' from 'F32' >> make[3]: *** [newview/CMakeFiles/secondlife-bin.dir/ >> llpreviewtexture.o] Error 1 >> >> It seems to be caused by your change as part of: >> r2215 | aimee.trescothick | 2009-05-02 10:30:43 -0700 (Sat, 02 May >> 2009) | 2 lines >> VWR-8008: Drop-down to select preset aspect ratios in texture preview >> floaters >> >> Would you mind to check this out? >> >> Thanks! >> >> Cheers, >> - Merov >> _______________________________________________ >> 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 seg at haxxed.com Mon May 4 22:21:32 2009 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 5 May 2009 00:21:32 -0500 Subject: [sldev] openjpeg bug on 64bit In-Reply-To: <20090423234145.GA24850@alinoe.com> References: <20090406175534.GA7852@alinoe.com> <20090423234145.GA24850@alinoe.com> Message-ID: <1218b5bc0905042221u3c19b21fv1999a5a9902630e6@mail.gmail.com> On Thu, Apr 23, 2009 at 6:41 PM, Carlo Wood wrote: > Heya Callum, > > I never saw a reply to this - neither, here in my Inbox > or on the openjpeg website. > > I assumed you were on a holiday or something, but > it has been almost 3 weeks now. Sorry, gmail seems to have stuffed this message away in my sldev folder that I rarely check anymore. I've kind of put the whole SL thing on the backburner, due in large part to the utter shambles the situation with OpenGL has become: https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00168.html It seems Dzonatas is taking a look. If anyone wants me you can find me in WoW. :P From tateru.nino at gmail.com Tue May 5 05:39:16 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue, 05 May 2009 22:39:16 +1000 Subject: [sldev] Anyone from the time of Dynamic Reflections still here? In-Reply-To: <49FF1C9A.5030000@lindenlab.com> References: <49FC2D87.3020602@Gmail.com> <49FD59D4.5000808@Gmail.com> <49FF1C9A.5030000@lindenlab.com> Message-ID: <4A003374.6030104@gmail.com> Brad Kittenbrink (Brad Linden) wrote: > Tigro Spottystripes wrote: > >> Stickman escreveu: >> >> >>>> I would like to know what happened exactly, at first it worked perfectly >>>> for me, then it stopped being supported cause it was crashing some >>>> people, then it started working worse and worse for me and eventually I >>>> couldn't even find it on the client at all. Is any Linden around that >>>> was around back when it all took place and knows the details of what >>>> happened? >>>> >>>> >>>> >>> I remember those! They were fun to play with. >>> >>> There were some issues if you went into mouselook with "show avatar in >>> mouselook" clicked, but they otherwise seemed to work well. >>> >>> I wasn't paying much attention at the time. I believe they were in an >>> RC. But I don't think they ever made it out, did they? >>> >>> I have a number of screenshots in my inventory about those... Here we go: >>> http://stickman.mach5.org/temp/sl-reflect.jpg >>> >>> Is that what we're talking about? >>> >>> -Stickman >>> >>> >>> >>> >> I think so, but I can't tell if those were already the versions that >> started misbehaving, I got a couple shots from the good version (and >> perhaps a one or two from when it was bad, I don't remember) on my >> galery at ProfilesLive ( >> http://www.profileslive.com/profilepictures.asp?id=4766 ) . I remember >> for some versions it reflected well, but the reflection map position >> snapped to coordinates several meters apart and somtimes it would >> reflect a point very far in the sim, there was also a time when the >> reflections where fuzzy no matter what resolution you set them to be, >> then the reflection was only updated the moment you turned Dynamic >> Reflections on and then stayed frozen, after that I think it would show >> some random scrapings of the video memory, and when Windlight arived, or >> perhaps some time later, it started messing up the screen if used in >> combination with Athmospheric Shaders, and eventually it was gone completly. >> >> I think it was a First Look and not a RC client, at least at first, but >> I have a slightly fuzzy memory of a debug setting for it reaching the >> main client even after the option in the Advanced (I think then it was >> called Client or perhaps Debug, I'm not sure) menu was gone, but that >> too was removed several versions later. >> >> > Well, I think I remember some discussions about whether to maintain > dynamic reflections when we began integrating Windlight, and the > decision was 'no'. At that point, I think it was a debug setting in the > release client, but the feature had been stagnant for some time. > > If I recall correctly, the reasons for leaving it unmaintained were that > the existing implementation was rather unscalable (in terms of video > memory usage and extra rendering passes) and could "never" have been > brought up to releasable quality. Work on Windlight integration broke > it, as the same code was now being used for the Windlight water, but not > being maintained for compatibility with existing dynamic reflections. > The debug setting was removed shortly thereafter. > > I may be recalling some things incorrectly here, but I think I got the > basics right. > I was recently shown some dynamic reflections in SL from a bit of shader hackery. And not very complicated hackery, I was led to understand. A perfect mirror was implemented. -- Tateru Nino http://www.massively.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090505/acb41b2a/attachment.htm From tillie at xp2.de Tue May 5 06:47:49 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Tue, 05 May 2009 15:47:49 +0200 Subject: [sldev] VS2008: Compile error Message-ID: <4A004385.1030101@xp2.de> Any idea what's wrong? Generating indra.y.cpp, indra.y.hpp e:/secondlife/dev/linden/indra/lscript/lscript_compile/indra.y contains 88 reduce/reduce conflicts. Kompilieren... indra.y.cpp e:/secondlife/dev/linden/indra/lscript/lscript_compile/indra.y(748) : error C2143: Syntaxfehler: Es fehlt ';' vor '-' e:/secondlife/dev/linden/indra/lscript/lscript_compile/indra.y(750) : fatal error C1021: Ung?ltiger Pr?prozessorbefehl "Yacc". Buildzeit 0:03 I have no idea * if those reduce/reduce conflicts are a problem * where there is a ; before - is missing, the given file/line is bullshit and even looking at indra.y.cpp didn't help * how to get rid of the fatal error about Yacc Tillie From chaosstar at gmail.com Tue May 5 06:55:06 2009 From: chaosstar at gmail.com (Ambrosia) Date: Tue, 5 May 2009 15:55:06 +0200 Subject: [sldev] VS2008: Compile error In-Reply-To: <4A004385.1030101@xp2.de> References: <4A004385.1030101@xp2.de> Message-ID: <9bb32d430905050655h2977c8aer674348d3c8fca3d5@mail.gmail.com> Hi there! Have you installed Cygwin? if so, when you installed it, did you check 'Yacc' and 'Bison' under the 'Development' category of packages? If you did so, did you install Cygwin under C:\cygwin? The project file uses it as the default location for bison and yacc, last I checked, tho I think an entry in the Windows environment PATH variable of your:\cygwinlocaton\bin shall do the trick as well. > e:/secondlife/dev/linden/indra/lscript/lscript_compile/indra.y(750) : fatal > error C1021: Ung?ltiger Pr?prozessorbefehl "Yacc". > Buildzeit 0:03 > > I have no idea From tillie at xp2.de Tue May 5 07:38:45 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Tue, 05 May 2009 16:38:45 +0200 Subject: [sldev] VS2008: Compile error In-Reply-To: <9bb32d430905050655h2977c8aer674348d3c8fca3d5@mail.gmail.com> References: <4A004385.1030101@xp2.de> <9bb32d430905050655h2977c8aer674348d3c8fca3d5@mail.gmail.com> Message-ID: <4A004F75.1060604@xp2.de> Ambrosia wrote: > Have you installed Cygwin? > if so, when you installed it, did you check 'Yacc' and 'Bison' under > the 'Development' category of packages? There is no Yacc in current cygwin. But I have installed bison and flex, and bison has a "yacc" shell script, which executes "bison -y". But probably that wont help in the VS2008 IDE. > If you did so, did you install Cygwin under C:\cygwin? The project > file uses it as the default location for bison and yacc, last I > checked, tho I think an entry in the Windows environment PATH variable > of your:\cygwinlocaton\bin shall do the trick as well. Different path but it's in the %PATH%, and I have added it's bin directory to VC2008's build paths, too. Tillie >> e:/secondlife/dev/linden/indra/lscript/lscript_compile/indra.y(750) : fatal >> error C1021: Ung?ltiger Pr?prozessorbefehl "Yacc". >> Buildzeit 0:03 >> >> I have no idea > From soft at lindenlab.com Tue May 5 07:44:09 2009 From: soft at lindenlab.com (Soft) Date: Tue, 5 May 2009 09:44:09 -0500 Subject: [sldev] VS2008: Compile error In-Reply-To: <4A004F75.1060604@xp2.de> References: <4A004385.1030101@xp2.de> <9bb32d430905050655h2977c8aer674348d3c8fca3d5@mail.gmail.com> <4A004F75.1060604@xp2.de> Message-ID: On Tue, May 5, 2009 at 9:38 AM, Tillie Ariantho wrote: >>> e:/secondlife/dev/linden/indra/lscript/lscript_compile/indra.y(750) : fatal >>> error C1021: Ung?ltiger Pr?prozessorbefehl "Yacc". >>> Buildzeit 0:03 >>> >>> I have no idea Which branch are you building, and what versions of flex and bison did it install? From tillie at xp2.de Tue May 5 08:10:33 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Tue, 05 May 2009 17:10:33 +0200 Subject: [sldev] VS2008: Compile error In-Reply-To: References: <4A004385.1030101@xp2.de> <9bb32d430905050655h2977c8aer674348d3c8fca3d5@mail.gmail.com> <4A004F75.1060604@xp2.de> Message-ID: <4A0056E9.2000008@xp2.de> Soft wrote: > On Tue, May 5, 2009 at 9:38 AM, Tillie Ariantho wrote: >>>> e:/secondlife/dev/linden/indra/lscript/lscript_compile/indra.y(750) : fatal >>>> error C1021: Ung?ltiger Pr?prozessorbefehl "Yacc". >>>> Buildzeit 0:03 >>>> >>>> I have no idea > > Which branch are you building, and what versions of flex and bison did > it install? Working with the 1.23 RC branch. Just found out: It found another bison while configuring. Modified all locations to the cygwin dir, now all three bugs got away. Now I am stuck with this one: C1083: Cannot open include file: 'unistd.h' That one is documented on http://wiki.secondlife.com/wiki/Common_compilation_problems , seems the source changes are already merged in, but the mentioned praeprocessor string doesn't help. Probably I dont have to edit them for lscript_compile but somewhere else? 1>Kompilieren... 1>indra.l.cpp 1>.\indra.l.cpp(26) : fatal error C1083: Datei (Include) kann nicht ge?ffnet werden: "unistd.h": No such file or directory 1>Buildzeit 0:13 Tillie From moriz.gupte at gmail.com Tue May 5 15:55:09 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Tue, 5 May 2009 16:55:09 -0600 Subject: [sldev] UI streamlining strategy Message-ID: Hey there, I am starting a new thread as a response to your suggestion. This idea resonates with a lot of us but for some reason did not follow through whenever it was raised (the one time I remember was a post on SLViews last year). I think shortcuts to rapid decisions e.g. votes work but it comes with some campaigning distractions.. There are well developed click path analyses, click through evaluations out there...and we could get inspired from them. I think gaze based evals (fixation/dwell analyses) have their place too and is to expected in a bleeding edge metaverse platform company. Extracting Usability Information from User Interface EventsEventseer.net - Understanding the user - logging and interpreting user interactions in information search and retrieval DATA LOGGING: HIGHER-LEVEL CAPTURING AND MULTI-LEVEL ABSTRACTING OF USER ACTIVITIES I think with Melinda's approach which she mentioned could be done fairly quickly would be a fantastic start. We could look into patterns of clicks, eliminate UI interactions, coalesce functions and so on. I imagine this approach should already be taking at LL so this info may be redundant. Ramesh I think Melinda Green has a great idea to collect usage data on the user interface, it would give a lot of information on how it is being used. I would expand it a bit and save all interactions (with the UI) sequential. That way we can also learn which actions are taken after each other, if it turn out button A and Z are always pressed after one another we could create button AZ and simplify. We might want to start a new chain to discuss this. Jeroen Frans > Executive Director > TheVesuviusGroup.com > SL: Frans Charming > > _______________________________________________ > 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 Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2 , Blog: http://snipurl.com/3p5op , Play2Train: http://www.play2train.org ----- The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge- Stephen Hawking and many others who found light through the cracks of knowledge. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090505/db077d57/attachment.htm From kf6kjg at gmail.com Tue May 5 17:20:34 2009 From: kf6kjg at gmail.com (Ricky) Date: Tue, 5 May 2009 17:20:34 -0700 Subject: [sldev] UI streamlining strategy In-Reply-To: References: Message-ID: <3bb9647e0905051720t7a529dfbldc4d618f8f6c8e1b@mail.gmail.com> Of course, this would be an opt-in clause? AKA a "Would you like to send your anonymous usage data to LL to help with improving our UI?" popup during the first run of the program. (DO NOT use the text I just wrote!! :P ) A lot of programs I use ask that question. Admittedly, I tend to hit "no" by default, but it would help prevent people from complaining about LL spying on them... (Ridiculous, I know!) Ricky aka Cron Stardust On Tue, May 5, 2009 at 3:55 PM, Moriz Gupte wrote: > Hey there, I am starting a new thread as a response to your suggestion. > This idea resonates with a lot of us but for some reason did not follow > through whenever it was raised (the one time I remember was a post on > SLViews last year). > I think shortcuts to rapid decisions e.g. votes work but it comes with some > campaigning distractions.. > There are well developed click path analyses, click through evaluations out > there...and we could get inspired from them. I think gaze based evals > (fixation/dwell analyses) have their place too and is to expected in a > bleeding edge metaverse platform company. > Extracting Usability Information from User Interface EventsEventseer.net > - Understanding the user - logging and interpreting user interactions in > information search and retrieval DATA > LOGGING: HIGHER-LEVEL CAPTURING AND MULTI-LEVEL ABSTRACTING OF USER > ACTIVITIES > I think with Melinda's approach which she mentioned could be done fairly > quickly would be a fantastic start. We could look into patterns of clicks, > eliminate UI interactions, coalesce functions and so on. > I imagine this approach should already be taking at LL so this info may be > redundant. > > Ramesh > > I think Melinda Green has a great idea to collect usage data on the user > interface, it would give a lot of information on how it is being used. I > would expand it a bit and save all interactions (with the UI) sequential. > That way we can also learn which actions are taken after each other, if it > turn out button A and Z are always pressed after one another we could create > button AZ and simplify. We might want to start a new chain to discuss this. > > > Jeroen Frans >> Executive Director >> TheVesuviusGroup.com >> SL: Frans Charming >> >> _______________________________________________ >> 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 > Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2, Blog: > http://snipurl.com/3p5op , Play2Train: http://www.play2train.org > ----- > The greatest enemy of knowledge is not ignorance, it is the illusion of > knowledge- Stephen Hawking and many others who found light through the > cracks of knowledge. > > > > > _______________________________________________ > 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/20090505/1f77a48d/attachment.htm From moriz.gupte at gmail.com Tue May 5 17:23:06 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Tue, 5 May 2009 18:23:06 -0600 Subject: [sldev] UI streamlining strategy In-Reply-To: <3bb9647e0905051720t7a529dfbldc4d618f8f6c8e1b@mail.gmail.com> References: <3bb9647e0905051720t7a529dfbldc4d618f8f6c8e1b@mail.gmail.com> Message-ID: yes we touched on this matter in the lip sync thread. I just moved it here.. data uploaded optionally on crash for e.g. On Tue, May 5, 2009 at 6:20 PM, Ricky wrote: > Of course, this would be an opt-in clause? AKA a "Would you like to send > your anonymous usage data to LL to help with improving our UI?" popup during > the first run of the program. (DO NOT use the text I just wrote!! :P ) > > A lot of programs I use ask that question. Admittedly, I tend to hit "no" > by default, but it would help prevent people from complaining about LL > spying on them... (Ridiculous, I know!) > > Ricky > aka Cron Stardust > > > On Tue, May 5, 2009 at 3:55 PM, Moriz Gupte wrote: > >> Hey there, I am starting a new thread as a response to your suggestion. >> This idea resonates with a lot of us but for some reason did not follow >> through whenever it was raised (the one time I remember was a post on >> SLViews last year). >> I think shortcuts to rapid decisions e.g. votes work but it comes with >> some campaigning distractions.. >> There are well developed click path analyses, click through evaluations >> out there...and we could get inspired from them. I think gaze based evals >> (fixation/dwell analyses) have their place too and is to expected in a >> bleeding edge metaverse platform company. >> Extracting Usability Information from User Interface EventsEventseer.net >> - Understanding the user - logging and interpreting user interactions in >> information search and retrieval DATA >> LOGGING: HIGHER-LEVEL CAPTURING AND MULTI-LEVEL ABSTRACTING OF USER >> ACTIVITIES >> I think with Melinda's approach which she mentioned could be done fairly >> quickly would be a fantastic start. We could look into patterns of clicks, >> eliminate UI interactions, coalesce functions and so on. >> I imagine this approach should already be taking at LL so this info may be >> redundant. >> >> Ramesh >> >> I think Melinda Green has a great idea to collect usage data on the user >> interface, it would give a lot of information on how it is being used. I >> would expand it a bit and save all interactions (with the UI) sequential. >> That way we can also learn which actions are taken after each other, if it >> turn out button A and Z are always pressed after one another we could create >> button AZ and simplify. We might want to start a new chain to discuss this. >> >> >> Jeroen Frans >>> Executive Director >>> TheVesuviusGroup.com >>> SL: Frans Charming >>> >>> _______________________________________________ >>> 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/20090505/a3f76545/attachment.htm From tigrospottystripes at gmail.com Tue May 5 17:36:28 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 05 May 2009 21:36:28 -0300 Subject: [sldev] UI streamlining strategy In-Reply-To: <3bb9647e0905051720t7a529dfbldc4d618f8f6c8e1b@mail.gmail.com> References: <3bb9647e0905051720t7a529dfbldc4d618f8f6c8e1b@mail.gmail.com> Message-ID: <4A00DB8C.5090402@Gmail.com> I already don't like that they keep chatlogs on the servers without us having a choice (besides not using SL at all or using external means to chat), I'm not 100% sure I could trust them to not include more than one would expect once this permission is given, though perhaps if a big enough amount of the respected open source community revised all the code involved in gathering the data on the client side and approved it perhaps I might consider providing consent for them to track my mouse, clicks, button presses and a few other things Ricky escreveu: > Of course, this would be an opt-in clause? AKA a "Would you like to > send your anonymous usage data to LL to help with improving our UI?" > popup during the first run of the program. (DO NOT use the text I just > wrote!! :P ) > > A lot of programs I use ask that question. Admittedly, I tend to hit > "no" by default, but it would help prevent people from complaining > about LL spying on them... (Ridiculous, I know!) > > Ricky > aka Cron Stardust > > On Tue, May 5, 2009 at 3:55 PM, Moriz Gupte > wrote: > > Hey there, I am starting a new thread as a response to your > suggestion. This idea resonates with a lot of us but for some > reason did not follow through whenever it was raised (the one time > I remember was a post on SLViews last year). > I think shortcuts to rapid decisions e.g. votes work but it comes > with some campaigning distractions.. > There are well developed click path analyses, click through > evaluations out there...and we could get inspired from them. I > think gaze based evals (fixation/dwell analyses) have their place > too and is to expected in a bleeding edge metaverse platform company. > > > Extracting Usability Information from User Interface > Events > > > Eventseer.net - Understanding the user - logging and > interpreting user interactions in information search and > retrieval > > > DATA LOGGING: HIGHER-LEVEL CAPTURING AND MULTI-LEVEL > ABSTRACTING OF USER ACTIVITIES > > > > I think with Melinda's approach which she mentioned could be done > fairly quickly would be a fantastic start. We could look into > patterns of clicks, eliminate UI interactions, coalesce functions > and so on. > I imagine this approach should already be taking at LL so this > info may be redundant. > > Ramesh > > I think Melinda Green has a great idea to collect usage data on > the user interface, it would give a lot of information on how it > is being used. I would expand it a bit and save all interactions > (with the UI) sequential. That way we can also learn which actions > are taken after each other, if it turn out button A and Z are > always pressed after one another we could create button AZ and > simplify. We might want to start a new chain to discuss this. > > > Jeroen Frans > Executive Director > TheVesuviusGroup.com > SL: Frans Charming > > _______________________________________________ > 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 > Bio: http://snipurl.com/3p5ap , LinkedIn profile: > http://snipurl.com/3p5o2 , Blog: http://snipurl.com/3p5op , > Play2Train: http://www.play2train.org > ----- > The greatest enemy of knowledge is not ignorance, it is the > illusion of knowledge- Stephen Hawking and many others who found > light through the cracks of knowledge. > > > > > _______________________________________________ > 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 I_really_needed_a_new_mailbox at gmx.de Tue May 5 17:48:34 2009 From: I_really_needed_a_new_mailbox at gmx.de (Zai Lynch) Date: Wed, 6 May 2009 02:48:34 +0200 Subject: [sldev] [I18N] localization of LSL editor hovertips possible? Message-ID: Heyas! :-) In order to provide a patch for WEB-1036, I looked into the current source and realized, that the hovertips of the LSL editor seem to be hardcoded in linden/indra/lscript/lscript_library/lscript_library.cpp At least this is my understanding so far (I'm not an expert and just guessing atm). Is it possible to localize them or is this an I18n bug/missing feature? Would it make sense to translate the text within lscript_library.cpp by now or is it unlikely to be any benefit (because it can't be implemented)? Greetz, zai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090506/ac9ada7b/attachment.htm From me at signpostmarv.name Tue May 5 17:56:18 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed, 06 May 2009 01:56:18 +0100 Subject: [sldev] [I18N] localization of LSL editor hovertips possible? In-Reply-To: References: Message-ID: <4A00E032.20508@signpostmarv.name> Could mebbe replace the LSL editor with something HTML + JS + based, similar to how Bespin works: http://labs.mozilla.com/projects/bespin/ ~ Marv. Zai Lynch wrote: > Heyas! :-) > > In order to provide a patch for WEB-1036 > , I looked into the > current source and realized, that the hovertips of the LSL editor seem > to be hardcoded in > linden/indra/lscript/lscript_library/lscript_library.cpp > At least this is my understanding so far (I'm not an expert and just > guessing atm). > Is it possible to localize them or is this an I18n bug/missing feature? > Would it make sense to translate the text within lscript_library.cpp > by now or is it unlikely to be any benefit (because it can't be > implemented)? > > Greetz, > zai > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20090506/12597ea2/attachment.bin From colin.kern at gmail.com Tue May 5 18:15:28 2009 From: colin.kern at gmail.com (Colin Kern) Date: Tue, 5 May 2009 18:15:28 -0700 Subject: [sldev] Anyone from the time of Dynamic Reflections still here? In-Reply-To: <4A003374.6030104@gmail.com> References: <49FC2D87.3020602@Gmail.com> <49FD59D4.5000808@Gmail.com> <49FF1C9A.5030000@lindenlab.com> <4A003374.6030104@gmail.com> Message-ID: <77c421f00905051815q5620bb25h1829e9b616328b46@mail.gmail.com> On Tue, May 5, 2009 at 5:39 AM, Tateru Nino wrote: > I was recently shown some dynamic reflections in SL from a bit of shader > hackery. And not very complicated hackery, I was led to understand. A > perfect mirror was implemented. If you're referring to what I've seen, it was done by building a house on its side, and then having the water level be where the mirror was, then using the water reflections to act as a mirror. He changed the water settings to remove ripples and things like that. So it's not really a useful trick to make reflective things. Colin From jesseSA at gmail.com Tue May 5 19:11:54 2009 From: jesseSA at gmail.com (jesseSA at gmail.com) Date: Wed, 06 May 2009 02:11:54 +0000 Subject: [sldev] Anyone from the time of Dynamic Reflections still here? In-Reply-To: <77c421f00905051815q5620bb25h1829e9b616328b46@mail.gmail.com> Message-ID: <000e0cd47d9c56d2c3046934eb39@google.com> Saw a really interesting concept last night. The inside of a house had reflective floors or at least it seemed that way until you cammed down. There was a space under the floor with mirror image prims of some of the objects above the floor which was actually mostly alpha. Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090506/bd27eaea/attachment.htm From soft at lindenlab.com Tue May 5 19:16:28 2009 From: soft at lindenlab.com (Soft) Date: Tue, 5 May 2009 21:16:28 -0500 Subject: [sldev] Anyone from the time of Dynamic Reflections still here? In-Reply-To: <000e0cd47d9c56d2c3046934eb39@google.com> References: <77c421f00905051815q5620bb25h1829e9b616328b46@mail.gmail.com> <000e0cd47d9c56d2c3046934eb39@google.com> Message-ID: On Tue, May 5, 2009 at 9:11 PM, wrote: > Saw a really interesting concept last night. The inside of a house had > reflective > floors or at least it seemed that way until you cammed down. > There was a space under the floor with mirror image prims of some of the > objects above the floor which was actually mostly alpha. That's a common trick in games. Usually there's a lower level of detail on the reflected bit. Also, search for "Neptune Lighting" in Second Life. They have a bar with great examples of this. From mrfrans at gmail.com Tue May 5 21:21:28 2009 From: mrfrans at gmail.com (Frans) Date: Wed, 6 May 2009 06:21:28 +0200 Subject: [sldev] UI streamlining strategy In-Reply-To: <4A00DB8C.5090402@Gmail.com> References: <3bb9647e0905051720t7a529dfbldc4d618f8f6c8e1b@mail.gmail.com> <4A00DB8C.5090402@Gmail.com> Message-ID: <7765f2c60905052121x5c99c5a4of97a0f391f2a8094@mail.gmail.com> Cool. This could give a bundle of information on how the interface is used. I agree though it would have to be opt-in and maybe only in public nighties and release candites. I expect users using those clients are more willing to share that info. On Wed, May 6, 2009 at 2:36 AM, Tigro Spottystripes < tigrospottystripes at gmail.com> wrote: > I already don't like that they keep chatlogs on the servers without us > having a choice (besides not using SL at all or using external means to > chat), I'm not 100% sure I could trust them to not include more than one > would expect once this permission is given, though perhaps if a big > enough amount of the respected open source community revised all the > code involved in gathering the data on the client side and approved it > perhaps I might consider providing consent for them to track my mouse, > clicks, button presses and a few other things > -- Jeroen Frans Executive Director TheVesuviusGroup.com SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090506/f2ee935c/attachment.htm From GordonWendt at gmail.com Tue May 5 22:36:24 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed, 6 May 2009 01:36:24 -0400 Subject: [sldev] UI streamlining strategy In-Reply-To: <4A00DB8C.5090402@Gmail.com> References: <3bb9647e0905051720t7a529dfbldc4d618f8f6c8e1b@mail.gmail.com> <4A00DB8C.5090402@Gmail.com> Message-ID: <493033a70905052236s2e72790dq17d39b8eacdbc5ec@mail.gmail.com> No more than World of Warcraft keeps logs of what goes on in their servers, that's not the best example I know. Users always have the options of deactivating their accounts and leaving otherwise when using ANY online service you agree that any interaction with their servers are logged. The reason this would need permission is that it's information that people wouldn't generally expect to get sent to the servers so it really would be a bit of a privacy violation to not give it as opt-in. Incidentally you do have other options, you can use SL text chat solely as a means to share your AIM name which is a communications means outside of SL, and for voice nothing is stopping you from setting up a Ventrilo or Teamspeak server which, going back to WoW, is exactly what the majority of people choose to do over WoW's built in voice feature/ -Gordon On Tue, May 5, 2009 at 8:36 PM, Tigro Spottystripes < tigrospottystripes at gmail.com> wrote: > I already don't like that they keep chatlogs on the servers without us > having a choice (besides not using SL at all or using external means to > chat), I'm not 100% sure I could trust them to not include more than one > would expect once this permission is given, though perhaps if a big > enough amount of the respected open source community revised all the > code involved in gathering the data on the client side and approved it > perhaps I might consider providing consent for them to track my mouse, > clicks, button presses and a few other things > > Ricky escreveu: > > Of course, this would be an opt-in clause? AKA a "Would you like to > > send your anonymous usage data to LL to help with improving our UI?" > > popup during the first run of the program. (DO NOT use the text I just > > wrote!! :P ) > > > > A lot of programs I use ask that question. Admittedly, I tend to hit > > "no" by default, but it would help prevent people from complaining > > about LL spying on them... (Ridiculous, I know!) > > > > Ricky > > aka Cron Stardust > > > > On Tue, May 5, 2009 at 3:55 PM, Moriz Gupte > > wrote: > > > > Hey there, I am starting a new thread as a response to your > > suggestion. This idea resonates with a lot of us but for some > > reason did not follow through whenever it was raised (the one time > > I remember was a post on SLViews last year). > > I think shortcuts to rapid decisions e.g. votes work but it comes > > with some campaigning distractions.. > > There are well developed click path analyses, click through > > evaluations out there...and we could get inspired from them. I > > think gaze based evals (fixation/dwell analyses) have their place > > too and is to expected in a bleeding edge metaverse platform company. > > > > > > Extracting Usability Information from User Interface > > Events < > http://www.fxpal.com/publications/FXPAL-PR-00-162.pdf> > > > > > > Eventseer.net - Understanding the user - logging and > > interpreting user interactions in information search and > > retrieval > > > > > > DATA LOGGING: HIGHER-LEVEL CAPTURING AND MULTI-LEVEL > > ABSTRACTING OF USER ACTIVITIES > > > > > > > > I think with Melinda's approach which she mentioned could be done > > fairly quickly would be a fantastic start. We could look into > > patterns of clicks, eliminate UI interactions, coalesce functions > > and so on. > > I imagine this approach should already be taking at LL so this > > info may be redundant. > > > > Ramesh > > > > I think Melinda Green has a great idea to collect usage data on > > the user interface, it would give a lot of information on how it > > is being used. I would expand it a bit and save all interactions > > (with the UI) sequential. That way we can also learn which actions > > are taken after each other, if it turn out button A and Z are > > always pressed after one another we could create button AZ and > > simplify. We might want to start a new chain to discuss this. > > > > > > Jeroen Frans > > Executive Director > > TheVesuviusGroup.com > > SL: Frans Charming > > > > _______________________________________________ > > 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 > > Bio: http://snipurl.com/3p5ap , LinkedIn profile: > > http://snipurl.com/3p5o2 , Blog: http://snipurl.com/3p5op , > > Play2Train: http://www.play2train.org > > ----- > > The greatest enemy of knowledge is not ignorance, it is the > > illusion of knowledge- Stephen Hawking and many others who found > > light through the cracks of knowledge. > > > > > > > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090506/103addb5/attachment-0001.htm From tateru.nino at gmail.com Tue May 5 22:50:58 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed, 06 May 2009 15:50:58 +1000 Subject: [sldev] UI streamlining strategy In-Reply-To: <493033a70905052236s2e72790dq17d39b8eacdbc5ec@mail.gmail.com> References: <3bb9647e0905051720t7a529dfbldc4d618f8f6c8e1b@mail.gmail.com> <4A00DB8C.5090402@Gmail.com> <493033a70905052236s2e72790dq17d39b8eacdbc5ec@mail.gmail.com> Message-ID: <4A012542.4060909@gmail.com> It's true that extensive logs are kept. Sony, for example, kept pretty much every scrap of data for Everquest - sufficient, I think, that you could replay the entire game-world from the logs. Your ISP can probably look up your complete web-browsing history if they care to also. Such logs are routine - I like to think that I'm just not interesting enough that someone with access is going to pry into my affairs. The logging is important, though. Otherwise it's hard to find out that something seriously crashes (for example) if you send an umlaut in an IM (this actually happened. More than once). Gordon Wendt wrote: > No more than World of Warcraft keeps logs of what goes on in their > servers, that's not the best example I know. Users always have the > options of deactivating their accounts and leaving otherwise when > using ANY online service you agree that any interaction with their > servers are logged. The reason this would need permission is that > it's information that people wouldn't generally expect to get sent to > the servers so it really would be a bit of a privacy violation to not > give it as opt-in. Incidentally you do have other options, you can > use SL text chat solely as a means to share your AIM name which is a > communications means outside of SL, and for voice nothing is stopping > you from setting up a Ventrilo or Teamspeak server which, going back > to WoW, is exactly what the majority of people choose to do over WoW's > built in voice feature/ > > -Gordon > > On Tue, May 5, 2009 at 8:36 PM, Tigro Spottystripes > > > wrote: > > I already don't like that they keep chatlogs on the servers without us > having a choice (besides not using SL at all or using external > means to > chat), I'm not 100% sure I could trust them to not include more > than one > would expect once this permission is given, though perhaps if a big > enough amount of the respected open source community revised all the > code involved in gathering the data on the client side and approved it > perhaps I might consider providing consent for them to track my mouse, > clicks, button presses and a few other things > > Ricky escreveu: > > Of course, this would be an opt-in clause? AKA a "Would you like to > > send your anonymous usage data to LL to help with improving our UI?" > > popup during the first run of the program. (DO NOT use the text > I just > > wrote!! :P ) > > > > A lot of programs I use ask that question. Admittedly, I tend to hit > > "no" by default, but it would help prevent people from complaining > > about LL spying on them... (Ridiculous, I know!) > > > > Ricky > > aka Cron Stardust > > > > On Tue, May 5, 2009 at 3:55 PM, Moriz Gupte > > > >> > wrote: > > > > Hey there, I am starting a new thread as a response to your > > suggestion. This idea resonates with a lot of us but for some > > reason did not follow through whenever it was raised (the > one time > > I remember was a post on SLViews last year). > > I think shortcuts to rapid decisions e.g. votes work but it > comes > > with some campaigning distractions.. > > There are well developed click path analyses, click through > > evaluations out there...and we could get inspired from them. I > > think gaze based evals (fixation/dwell analyses) have their > place > > too and is to expected in a bleeding edge metaverse platform > company. > > > > > > Extracting Usability Information from User Interface > > Events > > > > > > > Eventseer.net - Understanding the user - logging and > > interpreting user interactions in information search and > > retrieval > > > > > > DATA LOGGING: HIGHER-LEVEL CAPTURING AND MULTI-LEVEL > > ABSTRACTING OF USER ACTIVITIES > > > > > > > > I think with Melinda's approach which she mentioned could be > done > > fairly quickly would be a fantastic start. We could look into > > patterns of clicks, eliminate UI interactions, coalesce > functions > > and so on. > > I imagine this approach should already be taking at LL so this > > info may be redundant. > > > > Ramesh > > > > I think Melinda Green has a great idea to collect usage data on > > the user interface, it would give a lot of information on how it > > is being used. I would expand it a bit and save all interactions > > (with the UI) sequential. That way we can also learn which > actions > > are taken after each other, if it turn out button A and Z are > > always pressed after one another we could create button AZ and > > simplify. We might want to start a new chain to discuss this. > > > > > > Jeroen Frans > > Executive Director > > TheVesuviusGroup.com > > SL: Frans Charming > > > > _______________________________________________ > > 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 > > Bio: http://snipurl.com/3p5ap , LinkedIn profile: > > http://snipurl.com/3p5o2 , Blog: http://snipurl.com/3p5op , > > Play2Train: http://www.play2train.org > > ----- > > The greatest enemy of knowledge is not ignorance, it is the > > illusion of knowledge- Stephen Hawking and many others who found > > light through the cracks of knowledge. > > > > > > > > > > _______________________________________________ > > 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 > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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://www.massively.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090506/fa50a248/attachment.htm From secret.argent at gmail.com Wed May 6 01:52:59 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 6 May 2009 03:52:59 -0500 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FF1739.9060203@lindenlab.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com><493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com><49F867E1.6040805@watson.ibm.com><784490.3996.qm@web59104.mail.re1.yahoo.com><49F8AFAD.3040007@watson.ibm.com><1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com><49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com><493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> Message-ID: <6B9312EA-2A60-47E6-A022-632BF76C7FB1@gmail.com> On 2009-05-04, at 11:26, Joshua Bell wrote: > "A feature that's not enabled by default might as well not exist" Which is why Voice keeps getting turned on in updates? :( Which is why the network meters keep getting replaced by the stupid search box? :( > (2) Is the ability to disable lip-sync something that a significant > number of users will need? Anything that is computationally intensive is something a significant number of users will want to disable. From open at autistici.org Wed May 6 02:39:41 2009 From: open at autistici.org (Opensource Obscure) Date: Wed, 06 May 2009 09:39:41 +0000 Subject: [sldev] =?utf-8?q?Anyone_from_the_time_of_Dynamic_Reflections_sti?= =?utf-8?q?ll_here=3F?= In-Reply-To: References: <49FC2D87.3020602@Gmail.com> Message-ID: On Sun, 3 May 2009 18:27:31 -0700, Stickman wrote: > Q Linden's office hours at Wednesday, 8am-9am. > http://wiki.secondlife.com/wiki/Office_hours That's separate from the > 2pm open source meeting so you wouldn't be crashing the party or > anything. Q's ones are interesting and informative meetings (well, when/if residents don't keep raising policy issues at least). Highly recommended. Often Nyx Linden is present as well. Opensource Obscure From lilililihozak.88 at gmail.com Wed May 6 03:05:22 2009 From: lilililihozak.88 at gmail.com (lili berg) Date: Wed, 6 May 2009 14:35:22 +0430 Subject: [sldev] Avatar-user survey: PLEASE complete it Message-ID: <5ab940f60905060305u74a0d0b7sf3187a60c8a7a7be@mail.gmail.com> Hi there residents We?re busy with a consumer behaviour study in SL. The research is a joint project between researchers from two universities. Your participation in the research will be greatly appreciated. Please click on the following link http://survey.ufs.ac.za/index.php?id=105&survey=anlvp5bEZ6vGxpKmlg%3D%3D to take the survey. The survey is very short and easy to complete. Just follow the instructions. Thanks in advance for your participation. From bishopj at bishopphillips.com Wed May 6 03:31:24 2009 From: bishopj at bishopphillips.com (Jonathan Bishop) Date: Wed, 6 May 2009 20:31:24 +1000 Subject: [sldev] Avatar-user survey: PLEASE complete it In-Reply-To: <5ab940f60905060305u74a0d0b7sf3187a60c8a7a7be@mail.gmail.com> References: <5ab940f60905060305u74a0d0b7sf3187a60c8a7a7be@mail.gmail.com> Message-ID: Inappropriate use of this list. In spite of the University of the Free State URL, I would doubt this is legitimate as this is not the way university research surveys are conducted. I would think carefully before following this link (I have not). To start with, the invitation is missing the ethics committee authorization and university certification ID, and one would have to wonder what sampling approach involves the sldev list as an avatar sampling base. If we sent out an invitation for University research studies like this in Oz we would be up before the ethics committee in a flash. Note the non-university email address as the reply to. 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 lili berg Sent: Wednesday, 6 May 2009 8:05 PM To: sldev at lists.secondlife.com Subject: [sldev] Avatar-user survey: PLEASE complete it Hi there residents We're busy with a consumer behaviour study in SL. The research is a joint project between researchers from two universities. Your participation in the research will be greatly appreciated. Please click on the following link http://survey.ufs.ac.za/index.php?id=105&survey=anlvp5bEZ6vGxpKmlg%3D%3D to take the survey. The survey is very short and easy to complete. Just follow the instructions. Thanks in advance for your participation. _______________________________________________ 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 me at signpostmarv.name Wed May 6 04:56:26 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed, 06 May 2009 12:56:26 +0100 Subject: [sldev] VWR-13245 "Change quit dialog to the context of Second Life being a place/virtual world, not a self-contained application" Message-ID: <4A017AEA.2010809@signpostmarv.name> Could peeps swing by the feature request ? It's got a couple patches for changing the quit dialog to "Are you sure you want to leave Second Life?" with "Leave" and "Stay" instead of "Quit" and "Continue". http://jira.secondlife.com/browse/VWR-13245 ~ Marv. -------------- 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/20090506/57e2adeb/attachment.bin From q at lindenlab.com Wed May 6 05:31:12 2009 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed, 6 May 2009 08:31:12 -0400 Subject: [sldev] [I18N] localization of LSL editor hovertips possible? In-Reply-To: References: Message-ID: <102CF568-0018-4E87-AA4F-EE673797F359@lindenlab.com> On May 5, 2009, at 8:48 PM, Zai Lynch wrote: > Heyas! :-) > > In order to provide a patch for WEB-1036, I looked into the current > source and realized, that the hovertips of the LSL editor seem to be > hardcoded in linden/indra/lscript/lscript_library/lscript_library.cpp > At least this is my understanding so far (I'm not an expert and just > guessing atm). > Is it possible to localize them or is this an I18n bug/missing > feature? > Would it make sense to translate the text within lscript_library.cpp > by now or is it unlikely to be any benefit (because it can't be > implemented)? When this was originally written, we didn't have the LLTrans object (that pulls localized strings from strings.xml). It would be a good thing to let these strings be localized. However, the API for the LLScriptLibraryFunction constructor takes const char* parameters for these hovertips, which means that the change would have to be sweeping enough to change the API (I don't think we'd want to make a change that doesn't convert them to strings). Unfortunately, LLScriptLibrary is one of the parts of our code that is common to both viewer and simulator. As such, we're noticeably less likely to take open source patches. We'd certainly consider it, but it would require a good JIRA and a high quality, extremely constrained patch. Q -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090506/6e08048a/attachment.htm From secret.argent at gmail.com Wed May 6 02:14:06 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 6 May 2009 04:14:06 -0500 Subject: [sldev] [I18N] localization of LSL editor hovertips possible? In-Reply-To: <4A00E032.20508@signpostmarv.name> References: <4A00E032.20508@signpostmarv.name> Message-ID: <14005DBE-401B-49D7-8C8B-26207BD37BEA@gmail.com> On 2009-05-05, at 19:56, SignpostMarv Martin wrote: > Could mebbe replace the LSL editor with something HTML + JS + > based, similar to how Bespin works: http://labs.mozilla.com/projects/bespin/ AUGH! AUGH AUGH! Working on scripts when the client's lagged is already hard enough since they eliminated Async UI. From I_really_needed_a_new_mailbox at gmx.de Wed May 6 08:05:44 2009 From: I_really_needed_a_new_mailbox at gmx.de (Zai Lynch) Date: Wed, 6 May 2009 17:05:44 +0200 Subject: [sldev] [I18N] localization of LSL editor hovertips possible? In-Reply-To: <102CF568-0018-4E87-AA4F-EE673797F359@lindenlab.com> References: <102CF568-0018-4E87-AA4F-EE673797F359@lindenlab.com> Message-ID: I see.. I made a JIRA for this @ https://jira.secondlife.com/browse/VWR-13251 so it would be great if someone (OS contributor or LL employee) could adopt it. (I don't consider me beeing able to do so.) --zai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090506/36edd5a3/attachment.htm From monkowsk at watson.ibm.com Wed May 6 08:28:41 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 06 May 2009 11:28:41 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <6B9312EA-2A60-47E6-A022-632BF76C7FB1@gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com><493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com><49F867E1.6040805@watson.ibm.com><784490.3996.qm@web59104.mail.re1.yahoo.com><49F8AFAD.3040007@watson.ibm.com><1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com><49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com><493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <6B9312EA-2A60-47E6-A022-632BF76C7FB1@gmail.com> Message-ID: <4A01ACA9.2060504@watson.ibm.com> Argent Stonecutter wrote: >>(2) Is the ability to disable lip-sync something that a significant >>number of users will need? > > > Anything that is computationally intensive is something a significant > number of users will want to disable. So you're saying that because lip sync is computationally insignificant that few people would want to disable it? Mike From maggie at matrisync.com Wed May 6 09:09:49 2009 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Wed, 6 May 2009 12:09:49 -0400 Subject: [sldev] SLDev Digest, Vol 29, Issue 15 In-Reply-To: References: Message-ID: > Date: Wed, 6 May 2009 20:31:24 +1000 > From: "Jonathan Bishop" > Subject: Re: [sldev] Avatar-user survey: PLEASE complete it > To: > Inappropriate use of this list. > > In spite of the University of the Free State URL, I would doubt this is > legitimate as this is not the way university research surveys are conducted. > > > I would think carefully before following this link (I have not). ?To start > with, the invitation is missing the ethics committee authorization and > university certification ID, and one would have to wonder what sampling > approach involves the sldev list as an avatar sampling base. > > If we sent out an invitation for University research studies like this in Oz > we would be up before the ethics committee in a flash. This spam hit the scripters list too, where I mentioned the lack of research ethics compliance. I'd be in favor of banning the sender from both lists. Maggie Darwin From tateru.nino at gmail.com Wed May 6 10:03:33 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu, 07 May 2009 03:03:33 +1000 Subject: [sldev] SLDev Digest, Vol 29, Issue 15 In-Reply-To: References: Message-ID: <4A01C2E5.9060705@weblogsinc.com> At least four lists. Maggie Leber (sl: Maggie Darwin) wrote: >> Date: Wed, 6 May 2009 20:31:24 +1000 >> From: "Jonathan Bishop" >> Subject: Re: [sldev] Avatar-user survey: PLEASE complete it >> To: >> Inappropriate use of this list. >> >> In spite of the University of the Free State URL, I would doubt this is >> legitimate as this is not the way university research surveys are conducted. >> >> >> I would think carefully before following this link (I have not). To start >> with, the invitation is missing the ethics committee authorization and >> university certification ID, and one would have to wonder what sampling >> approach involves the sldev list as an avatar sampling base. >> >> If we sent out an invitation for University research studies like this in Oz >> we would be up before the ethics committee in a flash. >> > > This spam hit the scripters list too, where I mentioned the lack of > research ethics compliance. > > I'd be in favor of banning the sender from both lists. > > 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 > > -- Tateru Nino http://www.massively.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090507/da5e1b86/attachment.htm From monkowsk at watson.ibm.com Wed May 6 10:32:44 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 06 May 2009 13:32:44 -0400 Subject: [sldev] SLDev Viewer--code review Message-ID: <4A01C9BC.6020105@watson.ibm.com> I haven't heard any feedback on the preliminary page describing the SLDev Open Source Viewer project at http://wiki.secondlife.com/wiki/User:Mm_Alder/SLDev_Open_Source_Viewer but there's a lot to read there, so maybe people were scared away by its length, but I would particularly be interested in hearing comments on the code review section: > OK, so I'm completely making this part up, but this is the way I think it should happen. > > Every week open source developers and Lindens gather at a miniature Roman Coliseum on Hippotropolis. > > Contributors have added their names to a list on the wiki together with a link pointing to the PJIRA issue that describes their contributions and includes a patch file made against the current version of the SLDev open source. One by one the contributors are called before the Linden tribunal. Using voice chat and an in-world display showing the code with highlights on the changes, the contributor describes what that part of the code used to do and how this contribution makes it better. Developers politely ask questions using text chat, and the contributor answers them in turn. > > In the end, everyone learns something, and if the code is deemed worthy, the contribution is given a thumbs up approval. If not, lions. Or at least a second chance. > > Well that's the way I think it should work, except for the lions. Is this technically feasible in SL? If such a gathering were to take place, would anyone show up? I see it as a way to build a community, learn the viewer code, and get changes implemented. I think it would make life easier for reviewers as well. Anybody else see it this way? Or would it just be a waste of time? Does the mention of "voice chat" doom it from its inception? Mike Mm Alder From soft at lindenlab.com Wed May 6 10:42:48 2009 From: soft at lindenlab.com (Soft) Date: Wed, 6 May 2009 12:42:48 -0500 Subject: [sldev] [I18N] localization of LSL editor hovertips possible? In-Reply-To: References: <102CF568-0018-4E87-AA4F-EE673797F359@lindenlab.com> Message-ID: On Wed, May 6, 2009 at 10:05 AM, Zai Lynch wrote: > I see.. I made a JIRA for this @ > https://jira.secondlife.com/browse/VWR-13251 so it would be great if someone > (OS contributor or LL employee) could adopt it. (I don't consider me beeing > able to do so.) This would be pretty quick to hash out the code on, and I checked and the only place the descriptions were used server side is in debug code. The good news there is it sounds like the core guys are okay with losing the function descriptions, so long as the names are still printed. I'd probably generate the UI strings file from the code version with a quick sed expression, but there's room for error there. If someone will volunteer to take that version and test hovering the mouse over every single function tooltip to look for mistakes, I'll do this. From robla at lindenlab.com Wed May 6 10:46:09 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 06 May 2009 10:46:09 -0700 Subject: [sldev] SLDev Viewer--code review In-Reply-To: <4A01C9BC.6020105@watson.ibm.com> References: <4A01C9BC.6020105@watson.ibm.com> Message-ID: <4A01CCE1.9080805@lindenlab.com> On first skim, looks good. I've been meaning to read through that much more, as well as figure out how to merge it with this page: https://wiki.secondlife.com/wiki/HTTP_Texture_Development Rob On 05/06/2009 10:32 AM, Mike Monkowski wrote: > I haven't heard any feedback on the preliminary page describing the > SLDev Open Source Viewer project at > http://wiki.secondlife.com/wiki/User:Mm_Alder/SLDev_Open_Source_Viewer > but there's a lot to read there, so maybe people were scared away by its > length, but I would particularly be interested in hearing comments on > the code review section: > > >> OK, so I'm completely making this part up, but this is the way I think it should happen. >> >> Every week open source developers and Lindens gather at a miniature Roman Coliseum on Hippotropolis. >> >> Contributors have added their names to a list on the wiki together with a link pointing to the PJIRA issue that describes their contributions and includes a patch file made against the current version of the SLDev open source. One by one the contributors are called before the Linden tribunal. Using voice chat and an in-world display showing the code with highlights on the changes, the contributor describes what that part of the code used to do and how this contribution makes it better. Developers politely ask questions using text chat, and the contributor answers them in turn. >> >> In the end, everyone learns something, and if the code is deemed worthy, the contribution is given a thumbs up approval. If not, lions. Or at least a second chance. >> >> Well that's the way I think it should work, except for the lions. >> > > Is this technically feasible in SL? If such a gathering were to take > place, would anyone show up? I see it as a way to build a community, > learn the viewer code, and get changes implemented. I think it would > make life easier for reviewers as well. Anybody else see it this way? > Or would it just be a waste of time? Does the mention of "voice chat" > doom it from its inception? > > Mike > Mm Alder > _______________________________________________ > 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 Wed May 6 10:53:24 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 6 May 2009 19:53:24 +0200 Subject: [sldev] SLDev Viewer--code review In-Reply-To: <4A01C9BC.6020105@watson.ibm.com> References: <4A01C9BC.6020105@watson.ibm.com> Message-ID: <20090506175324.GA20240@alinoe.com> On Wed, May 06, 2009 at 01:32:44PM -0400, Mike Monkowski wrote: > Or would it just be a waste of time? Does the mention of "voice chat" > doom it from its inception? Main problems for me: I can never, ever, on Thurdays :( I don't have working voice, and even if I did - that is too much 'RL' to be mixed with SL. Aside from that... as said before: it is MORE work to review a patch than to write one, simply because so much information needed to check the correctness of a patch is not in the diff itself. Therefore each patch contributor should VERY hard try to be SURE that their patch is correct, and take all responsibility for that. Basically, if someone commits a patch that breaks things, the commit rights should be taken away. The whole review stuff could be seen to help committers find that last error they overlooked, but likely none of the reviewers will see what is wrong by looking at a diff and hearing the reasoning of the patch writer anyway... So yes, it's a waste of time. It would be more productive to have people discuss concepts (It does this, and I want it to do that, and this is basically how I want to achieve it) PRIOR to writing a patch and discuss it then. Also, people should be able to ask technical questions WHILE working on the patch and get fast feedback. [I'll post an example of such question in my next post] And again, to motivate committers to take their work seriously, there should be some kind of punishment when they commit something that is simply broken. It is better for someone to ask "I am assuming that this and that class is the ONLY class that keeps a pointer to this and that object (my patch relies on that), but is it garanteed, also in the future?" before committing a patch; then so just write it, produce silently a diff and hope that reviewers not only know the answer to the first question but actually see that the diff is written assuming said pre-condition. -- Carlo Wood From monkowsk at watson.ibm.com Wed May 6 10:56:36 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 06 May 2009 13:56:36 -0400 Subject: [sldev] Mercurial question Message-ID: <4A01CF54.6050707@watson.ibm.com> I had a look at the Mercurial (Hg) repository at http://bitbucket.org/lindenlab/http-texture/ and I can't figure out how to get to the diff display, the equivalent of Revision Log->View Changes on SVN Trac, the page that shows the changes in red, green, and white. Does such a thing exist with Hg? Mike From carlo at alinoe.com Wed May 6 11:04:12 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 6 May 2009 20:04:12 +0200 Subject: [sldev] Technical question Message-ID: <20090506180412.GB20240@alinoe.com> I wish to debug something that happens as a result of a server message - but I have no idea where to start (where to put the breakpoint). I can trigger this by editting a prim. For example-- I create a box, and then I change a value in the Object TAB (ie, position or rotation etc) and hit enter. This will send a message to the server. I am assuming that some feedback message will be returned by the server to tell my client that the prim changed. What would be ideal is if I could set a break- point somewhere where I can check WHICH object was changed (so that I'm sure that if the breakpoint is hit, it is what I need *), as opposed to for example set a break point in a function that is hit *every* message from the server. The latter obviously won't help much cause there are too many incoming messages. Can someone shine a light on this for me? What would be a good point to intercept this? -- Carlo Wood *) I think that an LLViewerObject point is unique, so comparing a pointer passed to the function that I have my break point in (with a gdb condition) should do the trick to break at the moment the prim under investigation changed. From tigrospottystripes at gmail.com Wed May 6 11:26:33 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 06 May 2009 15:26:33 -0300 Subject: [sldev] SLDev Viewer--code review In-Reply-To: <20090506175324.GA20240@alinoe.com> References: <4A01C9BC.6020105@watson.ibm.com> <20090506175324.GA20240@alinoe.com> Message-ID: <4A01D659.2060809@Gmail.com> Carlo Wood escreveu: > Therefore each patch contributor should VERY hard try > to be SURE that their patch is correct, and take all > responsibility for that. Basically, if someone commits > a patch that breaks things, the commit rights should > be taken away. > > > if it was like that on the other side of the firewall they would probably need to hire new programmers every few versions <.< From robla at lindenlab.com Wed May 6 11:32:31 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 06 May 2009 11:32:31 -0700 Subject: [sldev] http-texture build 2220 Message-ID: <4A01D7BF.5050906@lindenlab.com> Hi folks, Sorry for being a bit absent from the list, but I've been literally absent from work, and then trying to get caught up. Anyway, I've been playing around a bit with build 2220 from Monday night. Other than a cache corruption crasher on Mac (see http://jira.secondlife.com/browse/VWR-13255 ) this seems ok. The new minimap stuff and the texture upload preview are new features to this build which add a nice touch. Anyone else have any experience with this build? Rob -------- Original Message -------- Subject: [sldev-commits] Successful Build for http-texture (2220) Date: Mon, 4 May 2009 20:26:46 -0700 (PDT) From: buildadmin at lindenlab.com To: sldev-commits at lists.secondlife.com Linux: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2220/SecondLife-i686-1.23.0.2220.tar.bz2 http://secondlife.com/developers/opensource/downloads/2009/http-texture/2220/good-build.Linux Darwin: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2220/SecondLife_1_23_0_2220_OSS.dmg http://secondlife.com/developers/opensource/downloads/2009/http-texture/2220/good-build.Darwin CYGWIN: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2220/Second_Life_1-23-0-2220_OSS_Setup.exe http://secondlife.com/developers/opensource/downloads/2009/http-texture/2220/good-build.CYGWIN ------------------------------------------------------------------------ r2219 | aimee.trescothick | 2009-05-04 15:43:33 -0700 (Mon, 04 May 2009) | 3 lines Changed paths: M /projects/2009/http-texture/doc/contributions.txt M /projects/2009/http-texture/indra/newview/app_settings/settings.xml M /projects/2009/http-texture/indra/newview/llnetmap.cpp M /projects/2009/http-texture/indra/newview/llnetmap.h M /projects/2009/http-texture/indra/newview/llworldmapview.cpp M /projects/2009/http-texture/indra/newview/llworldmapview.h A /projects/2009/http-texture/indra/newview/skins/default/textures/map_avatar_32.tga A /projects/2009/http-texture/indra/newview/skins/default/textures/map_avatar_above_32.tga A /projects/2009/http-texture/indra/newview/skins/default/textures/map_avatar_below_32.tga A /projects/2009/http-texture/indra/newview/skins/default/textures/map_avatar_you_32.tga M /projects/2009/http-texture/indra/newview/skins/default/textures/textures.xml VWR-12748: Increase MiniMap zoom range, and magnify avatar markers at higher zoom levelsi (Includes artwork) ------------------------------------------------------------------------ r2220 | aimee.trescothick | 2009-05-04 18:48:34 -0700 (Mon, 04 May 2009) | 2 lines Changed paths: M /projects/2009/http-texture/indra/newview/llpreviewtexture.cpp Fix for r2215 / VWR-8008 which broke building on Linux due to a conversion from F32 to S32. ------------------------------------------------------------------------ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits From armin.weatherwax at googlemail.com Wed May 6 12:03:09 2009 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Wed, 6 May 2009 21:03:09 +0200 Subject: [sldev] SLDev Digest, Vol 29, Issue 15 In-Reply-To: <4A01C2E5.9060705@weblogsinc.com> References: <4A01C2E5.9060705@weblogsinc.com> Message-ID: <200905062103.09479.Armin.Weatherwax@gmail.com> Am Wednesday 06 May 2009 19:03:33 schrieb Tateru Nino: > At least four lists. > > Maggie Leber (sl: Maggie Darwin) wrote: > >> Date: Wed, 6 May 2009 20:31:24 +1000 > >> From: "Jonathan Bishop" > >> Subject: Re: [sldev] Avatar-user survey: PLEASE complete it > >> To: > >> Inappropriate use of this list. > >> > >> In spite of the University of the Free State URL, I would doubt this is > >> legitimate as this is not the way university research surveys are > >> conducted. > >> > >> > >> I would think carefully before following this link (I have not). To > >> start with, the invitation is missing the ethics committee authorization > >> and university certification ID, and one would have to wonder what > >> sampling approach involves the sldev list as an avatar sampling base. > >> > >> If we sent out an invitation for University research studies like this > >> in Oz we would be up before the ethics committee in a flash. > > > > This spam hit the scripters list too, where I mentioned the lack of > > research ethics compliance. > > > > I'd be in favor of banning the sender from both lists. > > honestly I have mixed feelings about the post in question. On the one hand I understand that people feel spammed (and I do feel spammed myself) by surveys, esp. when it's claimed to be for scientific research but without proof. On the other hand when I was student I had to let fill in people a lot of surveys for scientific research and my professors didn't think about providing anything that could have been used as proof that the survery was really university research. "And better not mention it is for the department of psychology, because that could be bad for compliance". Cool. And now get 100 particpants or you'll miss your course. "Hello, I can not tell you for whom I'm gathering data and what I'm up to because that would bad for the design, but please give me 100 answers about absolutely personal questions. I promise it's all anonymous". I know the research instrument of the post in question very well and that it is only useful for science, because its only a weak measure for the underlaying construct, so I tend to believe that this comes from another victim of professoral ignorance about the non-anonymity of the internet. I can not tell, could also be just spam and from somebody up to no good. To bring my post on topic: It's absolutely necessary to gather behavioural data, like the "UI streamlining strategy" thread shows. That includes gathering data about psychological constructs, if you don't want to waste your time and gazilobytes of storage. At the mentioned thread Frans is writing "I agree though it would have to be opt-in and maybe only in public nighties and release candites. I expect users using those clients are more willing to share that info.". This is a theory about behaviour, and by the way it fits very good to a common psychological theory about personality dimensions (see http://en.wikipedia.org/wiki/Big_Five_personality_traits#Openness_to_Experience). According to that theory it's also more likely that persons using public nighties and release candites are better informed about how to use more sophisticated features and more likely up to try new features. Bad sample though for getting to know what an average user would do. Shows that research is necessary and it needs to be planned carefully. So to learn from the post in question: what are the community standards to do scientific research, how can the researcher make clear this is not spam, this is not to abuse data, this is to help to find new solutions which are useful? Is there a wiki page or another ressource where researchers can learn how to do it right for not annoying people? Are there Lindens which can be contacted for scientific research purposes? Sorry for that post got way too long, but if you read that far I hope you understand why :) Armin From dmahalko at gmail.com Wed May 6 12:08:12 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed, 6 May 2009 14:08:12 -0500 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FFB14F.3070102@Gmail.com> References: <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> <49FFB14F.3070102@Gmail.com> Message-ID: While this is called lip sync, apparently it is really just "jaw-sync". What happens for the non-human avatars? It doesn't seem to make much sense for a cyborg to waggle its jaw... if it has one. Maybe have a pulsating-glow prim on its torso instead. And what about a jellyfish avatar? Might want to waggle some pairs of flexy flagellum around its umbrella. This setting doesn't really belong in the client prefs at all. It should be avatar-specific and so should end up in the avatar Appearance settings for each avatar to decide for itself whether or not to use, as well as how to use it or what prims to parameter-animate with it. Appearance.... [ x ] Enable voice lipsync effect: ( . ) Sync avatar jaw to voice . . . . Maximum mouth-open scaling: [ 2.000 ] . . . . [ x ] Sync attachments to jaw ( . ) Sync LSL-enabled prim attachments to voice In enabled attachment: default { attach( key id ) { // Enable attachment to receive lipsync scaling float MinScale = 0.0; float MaxScale = 1.0; float Linearity = 1.0; llLipSyncPrimParams( llGetKey(), FLEXY_TENSION, MinScale, MaxScale, Linearity ); } } Constants for setting prim parameters to be lipsynced. - SIZE_X, SIZE_Y, SIZE_Z, SIZE_ALL - SCALE_X, SCALE_Y, SCALE_Z, SCALE_ALL - COLOR_R, COLOR_B, COLOR_G, COLOR_ALL - TRANSPARENCY - GLOW - TWIST_BEGIN, TWIST_END - DIMPLE_BEGIN, DIMPLE_END - CUT_BEGIN, CUT_END - SKEW - TEXTURE_SCALE_X, TEXTURE_SCALE_Y - TEXTURE_ROTATION - FLEXY_TENSION - FLEXY_GRAVITY (etc) All constants include the MinScale, MaxScale, and Linearity scaling parameters, and params need to be sane for the particular prim parameter being animated. Prim voice-animation modifications would be client-side only and would not affect prim parameters on the server side. - Dale Mahalko / Scalar Tardis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090506/636c2161/attachment.htm From tigrospottystripes at gmail.com Wed May 6 12:10:55 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 06 May 2009 16:10:55 -0300 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> <49FFB14F.3070102@Gmail.com> Message-ID: <4A01E0BF.9080304@Gmail.com> Dale Mahalko escreveu: > While this is called lip sync, apparently it is really just "jaw-sync". > > What happens for the non-human avatars? It doesn't seem to make much > sense for a cyborg to waggle its jaw... if it has one. Maybe have a > pulsating-glow prim on its torso instead. And what about a jellyfish > avatar? Might want to waggle some pairs of flexy flagellum around its > umbrella. > > > This setting doesn't really belong in the client prefs at all. It > should be avatar-specific and so should end up in the avatar > Appearance settings for each avatar to decide for itself whether or > not to use, as well as how to use it or what prims to > parameter-animate with it. > > Appearance.... > [ x ] Enable voice lipsync effect: > ( . ) Sync avatar jaw to voice > . . . . Maximum mouth-open scaling: [ 2.000 ] > . . . . [ x ] Sync attachments to jaw > ( . ) Sync LSL-enabled prim attachments to voice > > > In enabled attachment: > > default > { > attach( key id ) > { > // Enable attachment to receive lipsync scaling > float MinScale = 0.0; > float MaxScale = 1.0; > float Linearity = 1.0; > llLipSyncPrimParams( llGetKey(), FLEXY_TENSION, MinScale, > MaxScale, Linearity ); > } > } > Constants for setting prim parameters to be lipsynced. > > - SIZE_X, SIZE_Y, SIZE_Z, SIZE_ALL > - SCALE_X, SCALE_Y, SCALE_Z, SCALE_ALL > - COLOR_R, COLOR_B, COLOR_G, COLOR_ALL > - TRANSPARENCY > - GLOW > - TWIST_BEGIN, TWIST_END > - DIMPLE_BEGIN, DIMPLE_END > - CUT_BEGIN, CUT_END > - SKEW > - TEXTURE_SCALE_X, TEXTURE_SCALE_Y > - TEXTURE_ROTATION > - FLEXY_TENSION > - FLEXY_GRAVITY > (etc) > > All constants include the MinScale, MaxScale, and Linearity scaling > parameters, and params need to be sane for the particular prim > parameter being animated. > > Prim voice-animation modifications would be client-side only and would > not affect prim parameters on the server side. > > > - Dale Mahalko / Scalar Tardis > I would vote for that :) From soft at lindenlab.com Wed May 6 13:00:08 2009 From: soft at lindenlab.com (Soft) Date: Wed, 6 May 2009 15:00:08 -0500 Subject: [sldev] Request review of VWR-13251 Revise lscript_library.cpp to allow localization of LSL editor hovertips Message-ID: On Wed, May 6, 2009 at 10:05 AM, Zai Lynch wrote: > I see.. I made a JIRA for this @ > https://jira.secondlife.com/browse/VWR-13251 so it would be great if someone > (OS contributor or LL employee) could adopt it. (I don't consider me beeing > able to do so.) I want to see if I understand the evolving open source review process, so I'm putting this change through SLDev instead of the internal review process. Please review the patch and test plan attached to VWR-13251 for errors or suggested improvements. Post a pass or any concerns to the list and JIRA both(?) https://jira.secondlife.com/browse/VWR-13251 If you willing to execute the test plan and post your results, that would be a huge plus. It doesn't require C++ knowledge, but LSL knowledge is helpful. If you can't build yourself, we should be able to kick off a new build of the branch after I get the okay to commit. From sllists at boroon.dasgupta.ch Wed May 6 13:12:31 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 06 May 2009 22:12:31 +0200 Subject: [sldev] Mercurial question In-Reply-To: <4A01CF54.6050707@watson.ibm.com> References: <4A01CF54.6050707@watson.ibm.com> Message-ID: <4A01EF2F.9030609@boroon.dasgupta.ch> Mike Monkowski schrieb: > I had a look at the Mercurial (Hg) repository at > http://bitbucket.org/lindenlab/http-texture/ and I can't figure out how > to get to the diff display, the equivalent of Revision Log->View Changes > on SVN Trac, the page that shows the changes in red, green, and white. > Does such a thing exist with Hg? * Click the "Changesets" tab (or go to http://bitbucket.org/lindenlab/http-texture/changesets) * Click either o the description of a changeset or o its commit ID (you'll get to e.g. http://bitbucket.org/lindenlab/http-texture/changeset/3c780aa6735e/) * Scroll down until you're past the list of changed files. I don't know if there's something similar on the bitbucket page for several changesets at once (e.g. the whole log or diff between to specific revisions), but you can always generate the specific diff you want from a local repository and color it by piping it through colordiff (see http://colordiff.sourceforge.net/ ; As it's a just perl script I guess it should work on Windows, too, maybe with cygwin). Though it doesn't seem to have any functionality the bitbucket page hasn't, have a look at *hg serve -v* (see http://hgbook.red-bean.com/read/collaborating-with-other-people.html#sec:collab:serve) I hope this helps Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090506/848778b0/attachment.htm From merov at lindenlab.com Wed May 6 13:16:39 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Wed, 6 May 2009 13:16:39 -0700 Subject: [sldev] Review request: VWR-12696 Bug fix (Blurry mini-map) In-Reply-To: <367CD852-3AB7-4C34-9452-56B3C5D55734@gmail.com> References: <367CD852-3AB7-4C34-9452-56B3C5D55734@gmail.com> Message-ID: Hi Aimee, Did a quick review of the patch and commented on the jira record. I think there's a possibility of memory leak. Could you check? Cheers, - Merov On May 4, 2009, at 5:57 PM, Aimee Trescothick wrote: > Hi, > > Would another committer mind running an eye over and testing my 3- > liner fix for http://jira.secondlife.com/browse/VWR-12696 so that I > can commit it? > > Aimee. > _______________________________________________ > 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 Wed May 6 13:17:29 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 06 May 2009 16:17:29 -0400 Subject: [sldev] Request review of VWR-13251 Revise lscript_library.cpp to allow localization of LSL editor hovertips In-Reply-To: References: Message-ID: <4A01F059.5060002@watson.ibm.com> Soft wrote: > If you can't build yourself, we should be able > to kick off a new build of the branch after I get the okay to commit. But doesn't the review come *before* the commit? Mike From aimee.trescothick at gmail.com Wed May 6 13:17:41 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Wed, 6 May 2009 21:17:41 +0100 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <4A01E0BF.9080304@Gmail.com> References: <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> <49FFB14F.3070102@Gmail.com> <4A01E0BF.9080304@Gmail.com> Message-ID: You can already achieve a similar effect for scripted attachments by using voice gestures to send a message on a channel, and then modifying position, or whatever you like, with a listening script. Aimee. On 6 May 2009, at 20:10, Tigro Spottystripes wrote: > Dale Mahalko escreveu: >> While this is called lip sync, apparently it is really just "jaw- >> sync". >> >> What happens for the non-human avatars? It doesn't seem to make much >> sense for a cyborg to waggle its jaw... if it has one. Maybe have a >> pulsating-glow prim on its torso instead. And what about a jellyfish >> avatar? Might want to waggle some pairs of flexy flagellum around its >> umbrella. >> >> >> This setting doesn't really belong in the client prefs at all. It >> should be avatar-specific and so should end up in the avatar >> Appearance settings for each avatar to decide for itself whether or >> not to use, as well as how to use it or what prims to >> parameter-animate with it. >> >> Appearance.... >> [ x ] Enable voice lipsync effect: >> ( . ) Sync avatar jaw to voice >> . . . . Maximum mouth-open scaling: [ 2.000 ] >> . . . . [ x ] Sync attachments to jaw >> ( . ) Sync LSL-enabled prim attachments to voice >> >> >> In enabled attachment: >> >> default >> { >> attach( key id ) >> { >> // Enable attachment to receive lipsync scaling >> float MinScale = 0.0; >> float MaxScale = 1.0; >> float Linearity = 1.0; >> llLipSyncPrimParams( llGetKey(), FLEXY_TENSION, MinScale, >> MaxScale, Linearity ); >> } >> } >> Constants for setting prim parameters to be lipsynced. >> >> - SIZE_X, SIZE_Y, SIZE_Z, SIZE_ALL >> - SCALE_X, SCALE_Y, SCALE_Z, SCALE_ALL >> - COLOR_R, COLOR_B, COLOR_G, COLOR_ALL >> - TRANSPARENCY >> - GLOW >> - TWIST_BEGIN, TWIST_END >> - DIMPLE_BEGIN, DIMPLE_END >> - CUT_BEGIN, CUT_END >> - SKEW >> - TEXTURE_SCALE_X, TEXTURE_SCALE_Y >> - TEXTURE_ROTATION >> - FLEXY_TENSION >> - FLEXY_GRAVITY >> (etc) >> >> All constants include the MinScale, MaxScale, and Linearity scaling >> parameters, and params need to be sane for the particular prim >> parameter being animated. >> >> Prim voice-animation modifications would be client-side only and >> would >> not affect prim parameters on the server side. >> >> >> - Dale Mahalko / Scalar Tardis >> > > I would vote for that :) > _______________________________________________ > 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 Wed May 6 13:22:38 2009 From: soft at lindenlab.com (Soft) Date: Wed, 6 May 2009 15:22:38 -0500 Subject: [sldev] Request review of VWR-13251 Revise lscript_library.cppto allow localization of LSL editor hovertips In-Reply-To: <4A01F059.5060002@watson.ibm.com> References: <4A01F059.5060002@watson.ibm.com> Message-ID: On Wed, May 6, 2009 at 3:17 PM, Mike Monkowski wrote: > Soft wrote: >> >> If you can't build yourself, we should be able >> to kick off a new build of the branch after I get the okay to commit. > > But doesn't the review come *before* the commit? In the full context, that was about the test plan, not the code review. Internally, the test plan is reviewed before the commit, by the same people who do code is reviews. Then, the approved test plan is executed by QA after the commit. It's a good question whether we use that same process in the open source branch. Suggestions? From soft at lindenlab.com Wed May 6 13:26:38 2009 From: soft at lindenlab.com (Soft) Date: Wed, 6 May 2009 15:26:38 -0500 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> <49FFB14F.3070102@Gmail.com> <4A01E0BF.9080304@Gmail.com> Message-ID: That's such an unfortunate (but clever) hack, though. Should we add voice level events for scripts that want them? That could still be passed up from the viewer, but without all that listener overhead. On Wed, May 6, 2009 at 3:17 PM, Aimee Trescothick wrote: > You can already achieve a similar effect for scripted attachments by > using voice gestures to send a message on a channel, and then > modifying position, or whatever you like, with a listening script. > > Aimee. > > On 6 May 2009, at 20:10, Tigro Spottystripes wrote: > >> Dale Mahalko escreveu: >>> While this is called lip sync, apparently it is really just "jaw- >>> sync". >>> >>> What happens for the non-human avatars? It doesn't seem to make much >>> sense for a cyborg to waggle its jaw... if it has one. Maybe have a >>> pulsating-glow prim on its torso instead. And what about a jellyfish >>> avatar? Might want to waggle some pairs of flexy flagellum around its >>> umbrella. >>> >>> >>> This setting doesn't really belong in the client prefs at all. It >>> should be avatar-specific and so should end up in the avatar >>> Appearance settings for each avatar to decide for itself whether or >>> not to use, as well as how to use it or what prims to >>> parameter-animate with it. >>> >>> Appearance.... >>> [ x ] Enable voice lipsync effect: >>> ( . ) Sync avatar jaw to voice >>> . . . . Maximum mouth-open scaling: [ 2.000 ] >>> . . . . [ x ] Sync attachments to jaw >>> ( . ) Sync LSL-enabled prim attachments to voice >>> >>> >>> In enabled attachment: >>> >>> default >>> { >>> ? ?attach( key id ) >>> ? ?{ >>> ? ? ? ?// Enable attachment to receive lipsync scaling >>> ? ? ? ?float MinScale = 0.0; >>> ? ? ? ?float MaxScale = 1.0; >>> ? ? ? ?float Linearity = 1.0; >>> ? ? ? ?llLipSyncPrimParams( llGetKey(), FLEXY_TENSION, MinScale, >>> MaxScale, Linearity ); >>> ? ?} >>> } >>> Constants for setting prim parameters to be lipsynced. >>> >>> - SIZE_X, SIZE_Y, SIZE_Z, SIZE_ALL >>> - SCALE_X, SCALE_Y, SCALE_Z, SCALE_ALL >>> - COLOR_R, COLOR_B, COLOR_G, COLOR_ALL >>> - TRANSPARENCY >>> - GLOW >>> - TWIST_BEGIN, TWIST_END >>> - DIMPLE_BEGIN, DIMPLE_END >>> - CUT_BEGIN, CUT_END >>> - SKEW >>> - TEXTURE_SCALE_X, TEXTURE_SCALE_Y >>> - TEXTURE_ROTATION >>> - FLEXY_TENSION >>> - FLEXY_GRAVITY >>> (etc) >>> >>> All constants include the MinScale, MaxScale, and Linearity scaling >>> parameters, and params need to be sane for the particular prim >>> parameter being animated. >>> >>> Prim voice-animation modifications would be client-side only and >>> would >>> not affect prim parameters on the server side. >>> >>> >>> - Dale Mahalko / Scalar Tardis >>> >> >> I would vote for that :) >> _______________________________________________ >> 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 mrfrans at gmail.com Wed May 6 13:32:38 2009 From: mrfrans at gmail.com (Frans) Date: Wed, 6 May 2009 22:32:38 +0200 Subject: [sldev] SLDev Digest, Vol 29, Issue 15 In-Reply-To: <200905062103.09479.Armin.Weatherwax@gmail.com> References: <4A01C2E5.9060705@weblogsinc.com> <200905062103.09479.Armin.Weatherwax@gmail.com> Message-ID: <7765f2c60905061332s652bf7b4rf183ca1e8bda65e5@mail.gmail.com> On Wed, May 6, 2009 at 9:03 PM, Armin Weatherwax < armin.weatherwax at googlemail.com> wrote: > Am Wednesday 06 May 2009 19:03:33 schrieb Tateru Nino: > > At least four lists. > > > I got in all the 13 SL/LL lists that I am subscribed to, 'luckily' gmail makes it all one giant thread. I suspect it was send to all public LL lists. All the tags it got automatically added to it, makes it look silly. :P > To bring my post on topic: It's absolutely necessary to gather behavioural > data, like the "UI streamlining strategy" thread shows. That includes > gathering data about psychological constructs, if you don't want to waste > your time and gazilobytes of storage. At the mentioned thread Frans is > writing "I agree though it would have to be opt-in and maybe only in public > nighties and release candites. I expect users using those clients are more > willing to share that info.". This is a theory about behaviour, and by the > way it fits very good to a common psychological theory about personality > dimensions (see > > http://en.wikipedia.org/wiki/Big_Five_personality_traits#Openness_to_Experience > ). > According to that theory it's also more likely that persons using public > nighties and release candites are better informed about how to use more > sophisticated features and more likely up to try new features. Bad sample > though for getting to know what an average user would do. > Shows that research is necessary and it needs to be planned carefully. Ah, you are right. Good to point that out! I still see myself as the average user, while really I'm not. -- Jeroen Frans Executive Director TheVesuviusGroup.com SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090506/1e77bb67/attachment.htm From dahliatrimble at gmail.com Wed May 6 13:37:30 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 6 May 2009 13:37:30 -0700 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> <49FFB14F.3070102@Gmail.com> <4A01E0BF.9080304@Gmail.com> Message-ID: Events would be helpful. The problem I had with doing lip sync with scripts was more related to the slow actions or long lead in/out times of the facial animations available to scripts. It took quite a bit of experimenting with combining facial animations and timing to come up with something usable. If there were faster responding morphs available, and if the amount of morph applied could be controlled by scripts, I think LSL based lip sync could be very competitive with the implementation in the viewer. Of course being able to continue to use LSL based facial animation might be compromised if there is no easy way to disable viewer based lip sync. On Wed, May 6, 2009 at 1:26 PM, Soft wrote: > That's such an unfortunate (but clever) hack, though. Should we add > voice level events for scripts that want them? That could still be > passed up from the viewer, but without all that listener overhead. > > On Wed, May 6, 2009 at 3:17 PM, Aimee Trescothick > wrote: > > You can already achieve a similar effect for scripted attachments by > > using voice gestures to send a message on a channel, and then > > modifying position, or whatever you like, with a listening script. > > > > Aimee. > > > > On 6 May 2009, at 20:10, Tigro Spottystripes wrote: > > > >> Dale Mahalko escreveu: > >>> While this is called lip sync, apparently it is really just "jaw- > >>> sync". > >>> > >>> What happens for the non-human avatars? It doesn't seem to make much > >>> sense for a cyborg to waggle its jaw... if it has one. Maybe have a > >>> pulsating-glow prim on its torso instead. And what about a jellyfish > >>> avatar? Might want to waggle some pairs of flexy flagellum around its > >>> umbrella. > >>> > >>> > >>> This setting doesn't really belong in the client prefs at all. It > >>> should be avatar-specific and so should end up in the avatar > >>> Appearance settings for each avatar to decide for itself whether or > >>> not to use, as well as how to use it or what prims to > >>> parameter-animate with it. > >>> > >>> Appearance.... > >>> [ x ] Enable voice lipsync effect: > >>> ( . ) Sync avatar jaw to voice > >>> . . . . Maximum mouth-open scaling: [ 2.000 ] > >>> . . . . [ x ] Sync attachments to jaw > >>> ( . ) Sync LSL-enabled prim attachments to voice > >>> > >>> > >>> In enabled attachment: > >>> > >>> default > >>> { > >>> attach( key id ) > >>> { > >>> // Enable attachment to receive lipsync scaling > >>> float MinScale = 0.0; > >>> float MaxScale = 1.0; > >>> float Linearity = 1.0; > >>> llLipSyncPrimParams( llGetKey(), FLEXY_TENSION, MinScale, > >>> MaxScale, Linearity ); > >>> } > >>> } > >>> Constants for setting prim parameters to be lipsynced. > >>> > >>> - SIZE_X, SIZE_Y, SIZE_Z, SIZE_ALL > >>> - SCALE_X, SCALE_Y, SCALE_Z, SCALE_ALL > >>> - COLOR_R, COLOR_B, COLOR_G, COLOR_ALL > >>> - TRANSPARENCY > >>> - GLOW > >>> - TWIST_BEGIN, TWIST_END > >>> - DIMPLE_BEGIN, DIMPLE_END > >>> - CUT_BEGIN, CUT_END > >>> - SKEW > >>> - TEXTURE_SCALE_X, TEXTURE_SCALE_Y > >>> - TEXTURE_ROTATION > >>> - FLEXY_TENSION > >>> - FLEXY_GRAVITY > >>> (etc) > >>> > >>> All constants include the MinScale, MaxScale, and Linearity scaling > >>> parameters, and params need to be sane for the particular prim > >>> parameter being animated. > >>> > >>> Prim voice-animation modifications would be client-side only and > >>> would > >>> not affect prim parameters on the server side. > >>> > >>> > >>> - Dale Mahalko / Scalar Tardis > >>> > >> > >> I would vote for that :) > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090506/718f6a4e/attachment-0001.htm From monkowsk at watson.ibm.com Wed May 6 13:59:33 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 06 May 2009 16:59:33 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> <49FFB14F.3070102@Gmail.com> Message-ID: <4A01FA35.8020200@watson.ibm.com> Dale Mahalko wrote: > While this is called lip sync, apparently it is really just "jaw-sync". > > What happens for the non-human avatars? It doesn't seem to make much > sense for a cyborg to waggle its jaw... if it has one. Maybe have a > pulsating-glow prim on its torso instead. And what about a jellyfish > avatar? Might want to waggle some pairs of flexy flagellum around its > umbrella. > > > This setting doesn't really belong in the client prefs at all. It should > be avatar-specific and so should end up in the avatar Appearance > settings for each avatar to decide for itself whether or not to use, as > well as how to use it or what prims to parameter-animate with it. "Lip sync" is a term from traditional animation and encompasses a variety of techniques. Specifically, this would be called a "mouth loop" or "babble loop" and it works with morphs (which are used only for avatars, not prims). There are also speech gestures in SL, which are animations that move the avatar bones (prims don't use bones either). I think these are avatar-specific. The animations are sent from the server, but run on the client. > Prim voice-animation modifications would be client-side only and would not affect prim parameters on the server side. It would be difficult to indicate that a particular attachment should be animated when its owner is speaking. You'd have to intercept the speech gesture animation intended for the avatar and tie it somehow to a script (prims don't use animations) in an attachment, but just execute the script client-side, modified by the messages coming from SLVoice. But there are no client-side scripts. I think if you had client-side scripts, though, it would be possible. Mike From monkowsk at watson.ibm.com Wed May 6 14:14:40 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 06 May 2009 17:14:40 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> <49FFB14F.3070102@Gmail.com> <4A01E0BF.9080304@Gmail.com> Message-ID: <4A01FDC0.4020409@watson.ibm.com> Aimee Trescothick wrote: > You can already achieve a similar effect for scripted attachments by > using voice gestures to send a message on a channel, ... I knew that messages could trigger gestures, but I didn't know gestures could send messages. How do you do that? Mike From tigrospottystripes at gmail.com Wed May 6 14:17:17 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 06 May 2009 18:17:17 -0300 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <4A01FA35.8020200@watson.ibm.com> References: <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> <49FFB14F.3070102@Gmail.com> <4A01FA35.8020200@watson.ibm.com> Message-ID: <4A01FE5D.1030604@Gmail.com> what about making the different voice levels and such be new controls, so scripts can take control and get updated info as soon as it is avaiable? Mike Monkowski escreveu: > Dale Mahalko wrote: > >> While this is called lip sync, apparently it is really just "jaw-sync". >> >> What happens for the non-human avatars? It doesn't seem to make much >> sense for a cyborg to waggle its jaw... if it has one. Maybe have a >> pulsating-glow prim on its torso instead. And what about a jellyfish >> avatar? Might want to waggle some pairs of flexy flagellum around its >> umbrella. >> >> >> This setting doesn't really belong in the client prefs at all. It should >> be avatar-specific and so should end up in the avatar Appearance >> settings for each avatar to decide for itself whether or not to use, as >> well as how to use it or what prims to parameter-animate with it. >> > > "Lip sync" is a term from traditional animation and encompasses a > variety of techniques. Specifically, this would be called a "mouth > loop" or "babble loop" and it works with morphs (which are used only for > avatars, not prims). > > There are also speech gestures in SL, which are animations that move the > avatar bones (prims don't use bones either). I think these are > avatar-specific. The animations are sent from the server, but run on > the client. > > >> Prim voice-animation modifications would be client-side only and would not affect prim parameters on the server side. >> > > It would be difficult to indicate that a particular attachment should be > animated when its owner is speaking. You'd have to intercept the speech > gesture animation intended for the avatar and tie it somehow to a script > (prims don't use animations) in an attachment, but just execute the > script client-side, modified by the messages coming from SLVoice. But > there are no client-side scripts. I think if you had client-side > scripts, though, it would be possible. > > 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 tigrospottystripes at gmail.com Wed May 6 14:18:47 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 06 May 2009 18:18:47 -0300 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <4A01FDC0.4020409@watson.ibm.com> References: <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> <49FFB14F.3070102@Gmail.com> <4A01E0BF.9080304@Gmail.com> <4A01FDC0.4020409@watson.ibm.com> Message-ID: <4A01FEB7.4070001@Gmail.com> add /number to the beggining of the Replace With field, and follow with the message you want sent in that channel :) (I don't think the say things bellow can do this too, I'm not sure) Mike Monkowski escreveu: > Aimee Trescothick wrote: > >> You can already achieve a similar effect for scripted attachments by >> using voice gestures to send a message on a channel, ... >> > > I knew that messages could trigger gestures, but I didn't know gestures > could send messages. How do you do that? > > 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 monkowsk at watson.ibm.com Wed May 6 14:21:39 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 06 May 2009 17:21:39 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> <49FFB14F.3070102@Gmail.com> <4A01E0BF.9080304@Gmail.com> Message-ID: <4A01FF63.4090708@watson.ibm.com> Soft wrote: > That's such an unfortunate (but clever) hack, though. Should we add > voice level events for scripts that want them? That could still be > passed up from the viewer, but without all that listener overhead. Voice level events come from the Vivox server through SLVoice to the viewer and are client-specific. Different avatars on the same sim get different voice levels. Scripts are run on the sim servers. There's no easy connection. Mike From ordinal.malaprop at fastmail.fm Wed May 6 14:25:11 2009 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop at fastmail.fm) Date: Wed, 6 May 2009 22:25:11 +0100 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> <49FB392D.3060004@lindenlab.com> <49FB80E7.9090205@watson.ibm.com> <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> <49FFB14F.3070102@Gmail.com> Message-ID: <616242CC-34CF-4A55-9223-DCBF68DA7A1C@fastmail.fm> Is there any potential for "lipsync" to actually affect the animation status of non-standard avatars? That is something that I had not thought of actually. It is something that should really be trappable by script to be honest. On 6 May 2009, at 20:08, Dale Mahalko wrote: > While this is called lip sync, apparently it is really just "jaw- > sync". > > What happens for the non-human avatars? It doesn't seem to make much > sense for a cyborg to waggle its jaw... if it has one. Maybe have a > pulsating-glow prim on its torso instead. And what about a jellyfish > avatar? Might want to waggle some pairs of flexy flagellum around > its umbrella. > > > This setting doesn't really belong in the client prefs at all. It > should be avatar-specific and so should end up in the avatar > Appearance settings for each avatar to decide for itself whether or > not to use, as well as how to use it or what prims to parameter- > animate with it. > > Appearance.... > [ x ] Enable voice lipsync effect: > ( . ) Sync avatar jaw to voice > . . . . Maximum mouth-open scaling: [ 2.000 ] > . . . . [ x ] Sync attachments to jaw > ( . ) Sync LSL-enabled prim attachments to voice > > > In enabled attachment: > > default > { > attach( key id ) > { > // Enable attachment to receive lipsync scaling > float MinScale = 0.0; > float MaxScale = 1.0; > float Linearity = 1.0; > llLipSyncPrimParams( llGetKey(), FLEXY_TENSION, MinScale, > MaxScale, Linearity ); > } > } > Constants for setting prim parameters to be lipsynced. > > - SIZE_X, SIZE_Y, SIZE_Z, SIZE_ALL > - SCALE_X, SCALE_Y, SCALE_Z, SCALE_ALL > - COLOR_R, COLOR_B, COLOR_G, COLOR_ALL > - TRANSPARENCY > - GLOW > - TWIST_BEGIN, TWIST_END > - DIMPLE_BEGIN, DIMPLE_END > - CUT_BEGIN, CUT_END > - SKEW > - TEXTURE_SCALE_X, TEXTURE_SCALE_Y > - TEXTURE_ROTATION > - FLEXY_TENSION > - FLEXY_GRAVITY > (etc) > > All constants include the MinScale, MaxScale, and Linearity scaling > parameters, and params need to be sane for the particular prim > parameter being animated. > > Prim voice-animation modifications would be client-side only and > would not affect prim parameters on the server side. > > > - Dale Mahalko / Scalar Tardis > > _______________________________________________ > 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 May 6 14:26:21 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 06 May 2009 18:26:21 -0300 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <4A01FF63.4090708@watson.ibm.com> References: <493033a70905011612vc976975sc513fa89f5a0e287@mail.gmail.com> <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> <49FFB14F.3070102@Gmail.com> <4A01E0BF.9080304@Gmail.com> <4A01FF63.4090708@watson.ibm.com> Message-ID: <4A02007D.1070505@Gmail.com> Mike Monkowski escreveu: > Soft wrote: > >> That's such an unfortunate (but clever) hack, though. Should we add >> voice level events for scripts that want them? That could still be >> passed up from the viewer, but without all that listener overhead. >> > > Voice level events come from the Vivox server through SLVoice to the > viewer and are client-specific. Different avatars on the same sim get > different voice levels. Scripts are run on the sim servers. There's no > easy connection. > > 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 > > the correct voice level is the local level, the person's own level, if someone is screaming at distance, visually they should still be screaming how about making the voice levels be a new control, so objects can take control and receive updates just as they happen? From soft at lindenlab.com Wed May 6 14:46:28 2009 From: soft at lindenlab.com (Soft) Date: Wed, 6 May 2009 16:46:28 -0500 Subject: [sldev] Technical question In-Reply-To: <20090506180412.GB20240@alinoe.com> References: <20090506180412.GB20240@alinoe.com> Message-ID: On Wed, May 6, 2009 at 1:04 PM, Carlo Wood wrote: > I wish to debug something that happens as a result > of a server message - but I have no idea where to > start (where to put the breakpoint). > > I can trigger this by editting a prim. For > example-- I create a box, and then I change > a value in the Object TAB (ie, position or > rotation etc) and hit enter. This will send a > message to the server. > > I am assuming that some feedback message will > be returned by the server to tell my client that > the prim changed. > > What would be ideal is if I could set a break- > point somewhere where I can check WHICH object > was changed (so that I'm sure that if the breakpoint > is hit, it is what I need *), as opposed to for > example set a break point in a function that is > hit *every* message from the server. The latter > obviously won't help much cause there are too > many incoming messages. > > Can someone shine a light on this for me? > What would be a good point to intercept this? The message handling functions (with very few exceptions) start with the name "process_"For server responses, it's always going to be one of these that you would want to hook first. In this case, process_object_update is the guy you're after, and that goes on to call LViewerObjectList::processObjectUpdate. The "fullid" unpacked from that message is a unique object ID, which you could check for in a conditional breakpoint. To learn the object ID, you could add an llinfos print to something like LLToolGrab::startGrab so it prints the ID of any object you click on. For discovering which messages you want, put a break on any process_ message and look up the call stack to see how messages are dispatched. You can add a little in the dispatcher that prints the name of every single message that arrives, and then start adding conditions to omit the most common messages. Keeping this in place and periodically filtering out messages you understand is a really great way to learn the client-server protocol. From soft at lindenlab.com Wed May 6 14:49:27 2009 From: soft at lindenlab.com (Soft) Date: Wed, 6 May 2009 16:49:27 -0500 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From ron at involve3d.com Wed May 6 16:10:16 2009 From: ron at involve3d.com (Ron Blechner) Date: Wed, 6 May 2009 19:10:16 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> <49FFB14F.3070102@Gmail.com> <4A01E0BF.9080304@Gmail.com> Message-ID: Yes please! A few potential uses I'd foresee: - The obvious - using it for non-human AVs, as a few of us have suggested. - An attachment that detects if someone's talking, and IMs the owner to alert them to the fact. I know sometimes I don't realize that people are on voice when I have it turned off (for whatever reason.) - Automated checks to make sure voice is on. If I'm an event host, for example, I could run a script that scans to make sure everyone has voice turned on, and alerts me who isn't - and I can ask them to talk, etc. - Integrating talking into games / environment. I'd love to say, have animals that get startled when they hear your noise. Or, imagine options sort of like Nintendo's DS - where a game might have you blow into it to trigger an event. -- Ron Blechner Chief Technology Officer Involve, Inc www.involve3d.com On Wed, May 6, 2009 at 4:26 PM, Soft wrote: > That's such an unfortunate (but clever) hack, though. Should we add > voice level events for scripts that want them? That could still be > passed up from the viewer, but without all that listener overhead. > > On Wed, May 6, 2009 at 3:17 PM, Aimee Trescothick > wrote: >> You can already achieve a similar effect for scripted attachments by >> using voice gestures to send a message on a channel, and then >> modifying position, or whatever you like, with a listening script. >> >> Aimee. >> >> On 6 May 2009, at 20:10, Tigro Spottystripes wrote: >> >>> Dale Mahalko escreveu: >>>> While this is called lip sync, apparently it is really just "jaw- >>>> sync". >>>> >>>> What happens for the non-human avatars? It doesn't seem to make much >>>> sense for a cyborg to waggle its jaw... if it has one. Maybe have a >>>> pulsating-glow prim on its torso instead. And what about a jellyfish >>>> avatar? Might want to waggle some pairs of flexy flagellum around its >>>> umbrella. >>>> >>>> >>>> This setting doesn't really belong in the client prefs at all. It >>>> should be avatar-specific and so should end up in the avatar >>>> Appearance settings for each avatar to decide for itself whether or >>>> not to use, as well as how to use it or what prims to >>>> parameter-animate with it. >>>> >>>> Appearance.... >>>> [ x ] Enable voice lipsync effect: >>>> ( . ) Sync avatar jaw to voice >>>> . . . . Maximum mouth-open scaling: [ 2.000 ] >>>> . . . . [ x ] Sync attachments to jaw >>>> ( . ) Sync LSL-enabled prim attachments to voice >>>> >>>> >>>> In enabled attachment: >>>> >>>> default >>>> { >>>> ? ?attach( key id ) >>>> ? ?{ >>>> ? ? ? ?// Enable attachment to receive lipsync scaling >>>> ? ? ? ?float MinScale = 0.0; >>>> ? ? ? ?float MaxScale = 1.0; >>>> ? ? ? ?float Linearity = 1.0; >>>> ? ? ? ?llLipSyncPrimParams( llGetKey(), FLEXY_TENSION, MinScale, >>>> MaxScale, Linearity ); >>>> ? ?} >>>> } >>>> Constants for setting prim parameters to be lipsynced. >>>> >>>> - SIZE_X, SIZE_Y, SIZE_Z, SIZE_ALL >>>> - SCALE_X, SCALE_Y, SCALE_Z, SCALE_ALL >>>> - COLOR_R, COLOR_B, COLOR_G, COLOR_ALL >>>> - TRANSPARENCY >>>> - GLOW >>>> - TWIST_BEGIN, TWIST_END >>>> - DIMPLE_BEGIN, DIMPLE_END >>>> - CUT_BEGIN, CUT_END >>>> - SKEW >>>> - TEXTURE_SCALE_X, TEXTURE_SCALE_Y >>>> - TEXTURE_ROTATION >>>> - FLEXY_TENSION >>>> - FLEXY_GRAVITY >>>> (etc) >>>> >>>> All constants include the MinScale, MaxScale, and Linearity scaling >>>> parameters, and params need to be sane for the particular prim >>>> parameter being animated. >>>> >>>> Prim voice-animation modifications would be client-side only and >>>> would >>>> not affect prim parameters on the server side. >>>> >>>> >>>> - Dale Mahalko / Scalar Tardis >>>> >>> >>> I would vote for that :) >>> _______________________________________________ >>> 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 Wed May 6 16:38:25 2009 From: melinda at superliminal.com (Melinda Green) Date: Wed, 06 May 2009 16:38:25 -0700 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <5A61915E6A00424F831DD423DBC574BC@neptune.priv> <49FF1739.9060203@lindenlab.com> <49FFAE82.6030409@beau.org> <49FFB14F.3070102@Gmail.com> <4A01E0BF.9080304@Gmail.com> Message-ID: <4A021F71.8030907@superliminal.com> Not only should animals startle, but so should other avatars. There's a wonderfully rich mechanism controlling avatar attention which you might notice causes avatars to look at people and things based on various events. When a nearby avatar types, there is currently a 50/50 chance that your avatar will look at them (assuming you're not focused on something considered to be more important). It often struck me as unfortunate that this system did not also apply to voice and other sound events. Of course this ability will encourage griefers to trigger this to get virtual attention, but that's a different problem. If a bomb goes off near me, I want my avatar to look that way even if I'm annoyed. It just looks silly when avatars carry on their conversations as if nothing had happened. -Melinda Ron Blechner wrote: > Yes please! > > A few potential uses I'd foresee: > > - The obvious - using it for non-human AVs, as a few of us have suggested. > - An attachment that detects if someone's talking, and IMs the owner > to alert them to the fact. I know sometimes I don't realize that > people are on voice when I have it turned off (for whatever reason.) > - Automated checks to make sure voice is on. If I'm an event host, for > example, I could run a script that scans to make sure everyone has > voice turned on, and alerts me who isn't - and I can ask them to talk, > etc. > - Integrating talking into games / environment. I'd love to say, have > animals that get startled when they hear your noise. Or, imagine > options sort of like Nintendo's DS - where a game might have you blow > into it to trigger an event. > > > > From kf6kjg at gmail.com Wed May 6 16:54:21 2009 From: kf6kjg at gmail.com (Ricky) Date: Wed, 6 May 2009 16:54:21 -0700 Subject: [sldev] [I18N] localization of LSL editor hovertips possible? In-Reply-To: References: <102CF568-0018-4E87-AA4F-EE673797F359@lindenlab.com> Message-ID: <3bb9647e0905061654x228778d0ha22f3e439c2844b8@mail.gmail.com> I'd be willing to volunteer for that. Just requires hovering over every function/event/etc and verifying that the tooltips are correct, right? Ricky aka, Cron Stardust On Wed, May 6, 2009 at 10:42 AM, Soft wrote: > On Wed, May 6, 2009 at 10:05 AM, Zai Lynch > wrote: > > I see.. I made a JIRA for this @ > > https://jira.secondlife.com/browse/VWR-13251 so it would be great if > someone > > (OS contributor or LL employee) could adopt it. (I don't consider me > beeing > > able to do so.) > > This would be pretty quick to hash out the code on, and I checked and > the only place the descriptions were used server side is in debug > code. The good news there is it sounds like the core guys are okay > with losing the function descriptions, so long as the names are still > printed. > > I'd probably generate the UI strings file from the code version with a > quick sed expression, but there's room for error there. If someone > will volunteer to take that version and test hovering the mouse over > every single function tooltip to look for mistakes, I'll do this. > _______________________________________________ > 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/20090506/21b290d8/attachment.htm From mhoda053 at uottawa.ca Wed May 6 17:01:37 2009 From: mhoda053 at uottawa.ca (Mohamad Hoda) Date: Wed, 6 May 2009 20:01:37 -0400 (EDT) Subject: [sldev] Retrieving 3D models Message-ID: <2964.137.122.201.77.1241654497.squirrel@webmail01.uottawa.ca> Hello there, I am developing a second life application. I just have a question. I want to search 3D models of different objects (e.g. cars, laptops, etc.) and use these retrieved 3D models from within my second life application. Is there any API to get these 3D models. Any information will be highly appreciated. Best Regards, Hoda From I_really_needed_a_new_mailbox at gmx.de Wed May 6 17:07:16 2009 From: I_really_needed_a_new_mailbox at gmx.de (Zai Lynch) Date: Thu, 7 May 2009 02:07:16 +0200 Subject: [sldev] [I18N] localization of LSL editor hovertips possible? In-Reply-To: <3bb9647e0905061654x228778d0ha22f3e439c2844b8@mail.gmail.com> References: <102CF568-0018-4E87-AA4F-EE673797F359@lindenlab.com> <3bb9647e0905061654x228778d0ha22f3e439c2844b8@mail.gmail.com> Message-ID: soft posted a testplan @ http://jira.secondlife.com/browse/VWR-13251 I'll try to test it too (when I figured it out ^^) 2009/5/7 Ricky > I'd be willing to volunteer for that. Just requires hovering over every > function/event/etc and verifying that the tooltips are correct, right? > > Ricky > aka, Cron Stardust > > On Wed, May 6, 2009 at 10:42 AM, Soft wrote: > >> On Wed, May 6, 2009 at 10:05 AM, Zai Lynch >> wrote: >> > I see.. I made a JIRA for this @ >> > https://jira.secondlife.com/browse/VWR-13251 so it would be great if >> someone >> > (OS contributor or LL employee) could adopt it. (I don't consider me >> beeing >> > able to do so.) >> >> This would be pretty quick to hash out the code on, and I checked and >> the only place the descriptions were used server side is in debug >> code. The good news there is it sounds like the core guys are okay >> with losing the function descriptions, so long as the names are still >> printed. >> >> I'd probably generate the UI strings file from the code version with a >> quick sed expression, but there's room for error there. If someone >> will volunteer to take that version and test hovering the mouse over >> every single function tooltip to look for mistakes, I'll do this. >> _______________________________________________ >> 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/20090507/d388bce1/attachment.htm From dmahalko at gmail.com Wed May 6 17:32:12 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed, 6 May 2009 19:32:12 -0500 Subject: [sldev] Technical question In-Reply-To: <20090506180412.GB20240@alinoe.com> References: <20090506180412.GB20240@alinoe.com> Message-ID: For the server edited-prim position updating you mention, back in 2006 I explored this thoroughly. Probably not much has changed in the client regarding how this works since then.. In-world prim editing seems like it is instantaneous to the client user for any number of selected prims, but results in a queued stream of position updates sent to the sim in the background. Then over time the sim progressively sends back its known position for each prim and the edited prims are repositioned with ther server's known position as the updating progresses. There is no status info provided of how long this client-to-server edit updating will take, but it takes progressively more and more time as the number of separate selected objects increases, or the available upstream bandwidth for your connection to SL decreases. You can "break" a loose pile of hundreds objects, by doing a quick series of edits before the background prim editing updates have completed. If the positioning updates have not finished between edits, the client just aborts updating the server and the intermediate prim edits get dropped, leaving you with a "half-edited" corrupted mess. I made some Google videos of this in 2006... Safely moving around a stack of 1458 separate prims by being patient and waiting however long it seems to take, to see if the background positioning updates have finished: http://video.google.com/videoplay?docid=-2327329216734064920 And here's how I screw up the stack by quickly moving it around without waiting for the intermediate background updates to finish: http://video.google.com/videoplay?docid=-8608210525014859556 (When the background edit-updates take more than 0.25 seconds to finish, it'd be nice for some sort of progress bar to pop up to warn people that the prim positions are still being sent to the server, and that they should not try editing it again just yet. But this is sufficiently arcane that I don't think a progress bar will ever happen.) This should probably be put in the open-source wiki somewhere, wherever the prim-edit server-update code is documented. - Dale Mahalko / Scalar Tardis On Wed, May 6, 2009 at 1:04 PM, Carlo Wood wrote: > I wish to debug something that happens as a result > of a server message - but I have no idea where to > start (where to put the breakpoint). > > I can trigger this by editting a prim. For > example-- I create a box, and then I change > a value in the Object TAB (ie, position or > rotation etc) and hit enter. This will send a > message to the server. > > I am assuming that some feedback message will > be returned by the server to tell my client that > the prim changed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090506/48125d8a/attachment-0001.htm From robla at lindenlab.com Wed May 6 17:59:08 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 06 May 2009 17:59:08 -0700 Subject: [sldev] Let's stay focused on getting a release out Message-ID: <4A02325C.504@lindenlab.com> Hi folks, There are now three open JIRA tasks associated with the lipsync issue: "Enable LipSync by default" http://jira.secondlife.com/browse/VWR-10311 "Create preference for toggling lip sync in Preferences" http://jira.secondlife.com/browse/VWR-13260 "Characterize performance impact of lipsync feature" http://jira.secondlife.com/browse/VWR-13263 As near as I can tell, all of the current discussion could be slotted into one of those three JIRA tasks, so I'd request that any further discussion on this issue occur there. It's alright to reraise the issue on this list once every couple of days, but please let's not resume the level of back-and-forth that we've had so far. The conclusion we've reached is yes, turn it on by default, but only after we have a patch that implements VWR-13260. I don't think there's anything more to be said about the performance impact of this feature, but if there is, let's finalize that in VWR-13263. On the topic of build 2220 (see my earlier mail): has anyone tried it? What is your experience with it? Rob From robla at lindenlab.com Wed May 6 18:13:19 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 06 May 2009 18:13:19 -0700 Subject: [sldev] lltexturefetch race condition Message-ID: <4A0235AF.5060500@lindenlab.com> In "Crash in lltexturefetch just after logging in" https://jira.secondlife.com/browse/VWR-12775 Robin writes: > Ok its a race condition between the > LLTextureFetchWorker::callbackDecoded() and > LLTextureFetchWorker::doWork() > > mState == DECODE_IMAGE kicks off the decode and sets the state machine > to DECODE_IMAGE_UPDATE, this does nothing until the decoded flag is > set, this is set in LLTextureFetchWorker::callbackDecoded(), but as > soon as its set, the state machine moves on and in the event of a > failed decode it sets mFormattedImage=NULL and sets the state machine > back to INIT > > but in LLTextureFetchWorker::callbackDecoded we have already passed > the check for STATE!=DECODE_IMAGE_UPDATE so the code moves on and then > finds itsself for a NULL mFormattedImage > > Adding a 2nd > > if (mState != DECODE_IMAGE_UPDATE) > > { llwarns << "Decode callback for " << mID << " with state = " << > mState << llendl; } > > after the > > mDecoded = TRUE; > > results in the 2nd warns message fireing every time mFormattedImage is > null here, the first warns *BEFORE* mDecoded-TRUE never fires so its a > race condition. > Based on my reading of things, this comment may have been overlooked. Couple of questions: 1. Does the comment above get us closer to a deeper fix for this problem? 2. Should we go ahead and apply the attached patches for this, even if they don't constitute a "real fix", because they do at least seem to keep us from crashing? Rob From soft at lindenlab.com Wed May 6 19:07:49 2009 From: soft at lindenlab.com (Soft) Date: Wed, 6 May 2009 21:07:49 -0500 Subject: [sldev] [I18N] localization of LSL editor hovertips possible? In-Reply-To: <3bb9647e0905061654x228778d0ha22f3e439c2844b8@mail.gmail.com> References: <102CF568-0018-4E87-AA4F-EE673797F359@lindenlab.com> <3bb9647e0905061654x228778d0ha22f3e439c2844b8@mail.gmail.com> Message-ID: Yup - there's a separate textfile attached to that issue, which can be pasted into an lsl editor. It includes every single function that should have a tooltip. As Zai says - some testing guidelines are included there as a test plan. Thanks! On Wed, May 6, 2009 at 6:54 PM, Ricky wrote: > I'd be willing to volunteer for that.? Just requires hovering over every > function/event/etc and verifying that the tooltips are correct, right? > > Ricky > aka, Cron Stardust > > On Wed, May 6, 2009 at 10:42 AM, Soft wrote: >> >> On Wed, May 6, 2009 at 10:05 AM, Zai Lynch >> wrote: >> > I see.. I made a JIRA for this @ >> > https://jira.secondlife.com/browse/VWR-13251 so it would be great if >> > someone >> > (OS contributor or LL employee) could adopt it. (I don't consider me >> > beeing >> > able to do so.) >> >> This would be pretty quick to hash out the code on, and I checked and >> the only place the descriptions were used server side is in debug >> code. The good news there is it sounds like the core guys are okay >> with losing the function descriptions, so long as the names are still >> printed. >> >> I'd probably generate the UI strings file from the code version with a >> quick sed expression, but there's room for error there. If someone >> will volunteer to take that version and test hovering the mouse over >> every single function tooltip to look for mistakes, I'll do this. >> _______________________________________________ >> 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 Wed May 6 19:21:45 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Wed, 6 May 2009 19:21:45 -0700 Subject: [sldev] SLDev Viewer--code review In-Reply-To: <4A01C9BC.6020105@watson.ibm.com> References: <4A01C9BC.6020105@watson.ibm.com> Message-ID: <383413B3-BBB4-452B-8EA5-24CBE02EE4D6@lindenlab.com> Hi, I've been ruminating that one, especially the "live" aspect of it. When it was proposed during the Hippo gathering I immediately said "why not?". Reading Mike's writing though, I'm wondering. Some elements of reflection: - Code reviews are good: I personally learned a lot along the years every time I was able to sit down with someone and go through code line by line, being my code or the one of others. - Committees are bad: That being said, doing this in a committee (i.e. 3 persons or more) is incredibly inefficient, unless the people know each other really well. The human psychology usually moves the objective of such gathering from "let's raise a barn together" to "who's the king of the hill". Terrible. - Live chat with others about code with some code in hand is a good idea: Coming up to someone with a problem and chatting about it often steers you in the right direction. And I'm a chatterbox so that suit me really well but others might feel differently and shouldn't be pushed out as a result. - One can't ignore RL realities: A formal process imposing real time constraints will leave part of the planet out (time zone conflicts). *Speaking* English will also be challenging for lots of us (reading and typing is easier). I for one am not a native english speaker and though I'm doing well now with English (despite a horrendous French accent), I do empathize with those who don't. In short, I'm wary of making a formal real time voice enabled presentation a requirement. With all that in hand. here's my stand on the subject: - "Formal" (format TBD) code review need to happen on the list and/or JIRA in writing: i.e. in the open, asynchronously, trackable. This is how I've seen it done in other projects. - Contributors *should* whenever possible get the help of others on IRC and/or IW in ad-hoc sessions with a reviewer. Definitely, I hear Mike's pledge for voice IW interaction. I miss it and I think it'll help us get to know each other and smooth the kinks in that group. Having an office hour of sort for some of us would make sense for instance. I'd be willing to have one and see how it works. Any takers? Cheers, - Merov On May 6, 2009, at 10:32 AM, Mike Monkowski wrote: > I haven't heard any feedback on the preliminary page describing the > SLDev Open Source Viewer project at > http://wiki.secondlife.com/wiki/User:Mm_Alder/SLDev_Open_Source_Viewer > but there's a lot to read there, so maybe people were scared away by > its > length, but I would particularly be interested in hearing comments on > the code review section: > >> OK, so I'm completely making this part up, but this is the way I >> think it should happen. >> >> Every week open source developers and Lindens gather at a miniature >> Roman Coliseum on Hippotropolis. >> >> Contributors have added their names to a list on the wiki together >> with a link pointing to the PJIRA issue that describes their >> contributions and includes a patch file made against the current >> version of the SLDev open source. One by one the contributors are >> called before the Linden tribunal. Using voice chat and an in-world >> display showing the code with highlights on the changes, the >> contributor describes what that part of the code used to do and how >> this contribution makes it better. Developers politely ask >> questions using text chat, and the contributor answers them in turn. >> >> In the end, everyone learns something, and if the code is deemed >> worthy, the contribution is given a thumbs up approval. If not, >> lions. Or at least a second chance. >> >> Well that's the way I think it should work, except for the lions. > > Is this technically feasible in SL? If such a gathering were to take > place, would anyone show up? I see it as a way to build a community, > learn the viewer code, and get changes implemented. I think it would > make life easier for reviewers as well. Anybody else see it this way? > Or would it just be a waste of time? Does the mention of "voice chat" > doom it from its inception? > > Mike > Mm Alder > _______________________________________________ > 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 May 6 20:39:01 2009 From: melinda at superliminal.com (Melinda Green) Date: Wed, 06 May 2009 20:39:01 -0700 Subject: [sldev] lltexturefetch race condition In-Reply-To: <4A0235AF.5060500@lindenlab.com> References: <4A0235AF.5060500@lindenlab.com> Message-ID: <4A0257D5.8030300@superliminal.com> Rob Lanphier wrote: > In "Crash in lltexturefetch just after logging in" > https://jira.secondlife.com/browse/VWR-12775 > > Robin writes: > >> Ok its a race condition between the >> LLTextureFetchWorker::callbackDecoded() and >> LLTextureFetchWorker::doWork() >> >> mState == DECODE_IMAGE kicks off the decode and sets the state machine >> to DECODE_IMAGE_UPDATE, this does nothing until the decoded flag is >> set, this is set in LLTextureFetchWorker::callbackDecoded(), but as >> soon as its set, the state machine moves on and in the event of a >> failed decode it sets mFormattedImage=NULL and sets the state machine >> back to INIT >> >> but in LLTextureFetchWorker::callbackDecoded we have already passed >> the check for STATE!=DECODE_IMAGE_UPDATE so the code moves on and then >> finds itsself for a NULL mFormattedImage >> >> Adding a 2nd >> >> if (mState != DECODE_IMAGE_UPDATE) >> >> { llwarns << "Decode callback for " << mID << " with state = " << >> mState << llendl; } >> >> after the >> >> mDecoded = TRUE; >> >> results in the 2nd warns message fireing every time mFormattedImage is >> null here, the first warns *BEFORE* mDecoded-TRUE never fires so its a >> race condition. >> >> > > Based on my reading of things, this comment may have been overlooked. > Couple of questions: > 1. Does the comment above get us closer to a deeper fix for this problem? > 2. Should we go ahead and apply the attached patches for this, even if > they don't constitute a "real fix", because they do at least seem to > keep us from crashing? > > Rob Regarding 1: I'd say "Probably". Whoever does attempt a deep fix will now know of some great places to set breakpoints. Regarding 2: I'd say "Why not?". Avoiding a crash is better than not. Avoiding this crashe won't make it harder to find a deep fix but it will remove a lot of the urgency to attempt one. But then that has to be a good thing too, right? BTW, I don't have the surrounding code to examine but one strange looking thing in the patches is that image objects appear to be used inconsistently in that one block or even a single expression will use both "." and "->" to dereference one of these objects. Since these appear to not be simple pointer objects I'd expect that we'd want to use the dot notation throughout. -Melinda From mwhite at leporidae.net Wed May 6 20:32:32 2009 From: mwhite at leporidae.net (Matt White) Date: Wed, 6 May 2009 23:32:32 -0400 Subject: [sldev] http-texture build 2220 In-Reply-To: <4A01D7BF.5050906@lindenlab.com> References: <4A01D7BF.5050906@lindenlab.com> Message-ID: On Wed, May 6, 2009 at 2:32 PM, Rob Lanphier wrote: > Anyone else have any experience with this build? Been using it all evening. Two crashes (and the crash dump reporter was able to send), but overall, this build is *MUCH* better than the last one posted here. Build 2200 is actually stable enough that I'm willing to use it - the last one wouldn't make it more than five minutes or so without falling over. Even with shadows turned on, this build seems to be better than the 1.23 RC0 client. (Vista64 with an nVidia GTX260.) I'm impressed! :) - Matt From kf6kjg at gmail.com Wed May 6 20:52:38 2009 From: kf6kjg at gmail.com (Ricky) Date: Wed, 6 May 2009 20:52:38 -0700 Subject: [sldev] SLDev Viewer--code review In-Reply-To: <383413B3-BBB4-452B-8EA5-24CBE02EE4D6@lindenlab.com> References: <4A01C9BC.6020105@watson.ibm.com> <383413B3-BBB4-452B-8EA5-24CBE02EE4D6@lindenlab.com> Message-ID: <3bb9647e0905062052k717006d2t27adb1ba809e9885@mail.gmail.com> Couldn't be a bad thing :D Ricky aka Cron Stardust On Wed, May 6, 2009 at 7:21 PM, Philippe Bossut (Merov Linden) < merov at lindenlab.com> wrote: > Hi, > > I've been ruminating that one, especially the "live" aspect of it. > When it was proposed during the Hippo gathering I immediately said > "why not?". Reading Mike's writing though, I'm wondering. Some > elements of reflection: > - Code reviews are good: I personally learned a lot along the years > every time I was able to sit down with someone and go through code > line by line, being my code or the one of others. > - Committees are bad: That being said, doing this in a committee (i.e. > 3 persons or more) is incredibly inefficient, unless the people know > each other really well. The human psychology usually moves the > objective of such gathering from "let's raise a barn together" to > "who's the king of the hill". Terrible. > - Live chat with others about code with some code in hand is a good > idea: Coming up to someone with a problem and chatting about it often > steers you in the right direction. And I'm a chatterbox so that suit > me really well but others might feel differently and shouldn't be > pushed out as a result. > - One can't ignore RL realities: A formal process imposing real time > constraints will leave part of the planet out (time zone conflicts). > *Speaking* English will also be challenging for lots of us (reading > and typing is easier). I for one am not a native english speaker and > though I'm doing well now with English (despite a horrendous French > accent), I do empathize with those who don't. In short, I'm wary of > making a formal real time voice enabled presentation a requirement. > > With all that in hand. here's my stand on the subject: > - "Formal" (format TBD) code review need to happen on the list and/or > JIRA in writing: i.e. in the open, asynchronously, trackable. This is > how I've seen it done in other projects. > - Contributors *should* whenever possible get the help of others on > IRC and/or IW in ad-hoc sessions with a reviewer. Definitely, I hear > Mike's pledge for voice IW interaction. I miss it and I think it'll > help us get to know each other and smooth the kinks in that group. > Having an office hour of sort for some of us would make sense for > instance. I'd be willing to have one and see how it works. Any takers? > > Cheers, > - Merov > > On May 6, 2009, at 10:32 AM, Mike Monkowski wrote: > > > I haven't heard any feedback on the preliminary page describing the > > SLDev Open Source Viewer project at > > http://wiki.secondlife.com/wiki/User:Mm_Alder/SLDev_Open_Source_Viewer > > but there's a lot to read there, so maybe people were scared away by > > its > > length, but I would particularly be interested in hearing comments on > > the code review section: > > > >> OK, so I'm completely making this part up, but this is the way I > >> think it should happen. > >> > >> Every week open source developers and Lindens gather at a miniature > >> Roman Coliseum on Hippotropolis. > >> > >> Contributors have added their names to a list on the wiki together > >> with a link pointing to the PJIRA issue that describes their > >> contributions and includes a patch file made against the current > >> version of the SLDev open source. One by one the contributors are > >> called before the Linden tribunal. Using voice chat and an in-world > >> display showing the code with highlights on the changes, the > >> contributor describes what that part of the code used to do and how > >> this contribution makes it better. Developers politely ask > >> questions using text chat, and the contributor answers them in turn. > >> > >> In the end, everyone learns something, and if the code is deemed > >> worthy, the contribution is given a thumbs up approval. If not, > >> lions. Or at least a second chance. > >> > >> Well that's the way I think it should work, except for the lions. > > > > Is this technically feasible in SL? If such a gathering were to take > > place, would anyone show up? I see it as a way to build a community, > > learn the viewer code, and get changes implemented. I think it would > > make life easier for reviewers as well. Anybody else see it this way? > > Or would it just be a waste of time? Does the mention of "voice chat" > > doom it from its inception? > > > > Mike > > Mm Alder > > _______________________________________________ > > 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/20090506/af5c0c92/attachment-0001.htm From kf6kjg at gmail.com Wed May 6 21:14:05 2009 From: kf6kjg at gmail.com (Ricky) Date: Wed, 6 May 2009 21:14:05 -0700 Subject: [sldev] Patchy whitespace Message-ID: <3bb9647e0905062114k6925f39aob1752f74ca9e4347@mail.gmail.com> I've been seeing a bit of discussion on the handling of whitespace in the diffs... Would patch's -l (lowercase L) flag be helpful? Or would it hinder by hiding some other issue? Here's the relevant section from the man page: -l or --ignore-whitespace Match patterns loosely, in case tabs or spaces have been munged in your files. Any sequence of one or more blanks in the patch file matches any sequence in the original file, and sequences of blanks at the ends of lines are ignored. Normal characters must still match exactly. Each line of the context must still match a line in the original file. Ricky aka Cron Stardust -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090506/c04dfe7c/attachment.htm From melinda at superliminal.com Wed May 6 22:26:33 2009 From: melinda at superliminal.com (Melinda Green) Date: Wed, 06 May 2009 22:26:33 -0700 Subject: [sldev] Patchy whitespace In-Reply-To: <3bb9647e0905062114k6925f39aob1752f74ca9e4347@mail.gmail.com> References: <3bb9647e0905062114k6925f39aob1752f74ca9e4347@mail.gmail.com> Message-ID: <4A027109.3030906@superliminal.com> I think that could help developers who don't have complete control of how their editors handle whitespace, but it doesn't help with the problem of rectifying inconsistent whitespace in the code base. I suppose we could blindly run a good pretty-printer on all the code but it almost certainly wouldn't do a perfect job (especially with comments) and would carry other costs and risks. Weather or not it'd be worth the costs would depend upon the state of the art which I don't currently know. -Melinda Ricky wrote: > I've been seeing a bit of discussion on the handling of whitespace in > the diffs... Would patch's -l (lowercase L) flag be helpful? Or > would it hinder by hiding some other issue? > > Here's the relevant section from the man page: > -l or --ignore-whitespace > Match patterns loosely, in case tabs or spaces have been > munged in your files. Any sequence of one or more blanks in the patch > file matches any sequence in the original file, and > sequences of blanks at the ends of lines are ignored. Normal > characters must > still match exactly. Each line of the context must still > match a line in the original file. > > Ricky > aka Cron Stardust From kf6kjg at gmail.com Wed May 6 23:11:02 2009 From: kf6kjg at gmail.com (Ricky) Date: Wed, 6 May 2009 23:11:02 -0700 Subject: [sldev] ZLib and Boost Message-ID: <3bb9647e0905062311t1e47c399p16b072ee9dd3d092@mail.gmail.com> Have the version requirements for zlib and boost changed recently (as in within the last 3 months)? I get the following error on compile, and the last time I compiled, (April 16 according to my logs,) it ran just fine... /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /lib64/libz.so when searching for -lz /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /lib64/libz.so when searching for -lz /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../libboost_signals-mt.so when searching for -lboost_signals-mt /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libboost_signals-mt.so when searching for -lboost_signals-mt /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lboost_signals-mt collect2: ld returned 1 exit status I'm compiling against trunk, revision 2227. (Latest edition as of this writing.) Thanks, Ricky aka Cron Stardust -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090506/a9f21446/attachment.htm From carlo at alinoe.com Thu May 7 05:06:04 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 7 May 2009 14:06:04 +0200 Subject: [sldev] Can message_template.msg be changed, or will that break third party applications? Message-ID: <20090507120604.GA29383@alinoe.com> Is there a problem with changing app_settings/message_template.msg as I suggest here: http://jira.secondlife.com/browse/VWR-13267 that I'm overlooking? -- Carlo Wood From soft at lindenlab.com Thu May 7 05:45:44 2009 From: soft at lindenlab.com (Soft) Date: Thu, 7 May 2009 07:45:44 -0500 Subject: [sldev] Can message_template.msg be changed, or will that break third party applications? In-Reply-To: <20090507120604.GA29383@alinoe.com> References: <20090507120604.GA29383@alinoe.com> Message-ID: On Thu, May 7, 2009 at 7:06 AM, Carlo Wood wrote: > Is there a problem with changing app_settings/message_template.msg > as I suggest here: > > http://jira.secondlife.com/browse/VWR-13267 > > that I'm overlooking? On the server, it reads it as a U8, but it's only using it to feed methods that want BOOLs. This really should have been a BOOL, as you point out. Since BOOL and U8 are the same size, it may be okay to change this over and to change the server code to unpack a BOOL to avoid introducing a warning there. I'm not sure how much havoc this change would wreak with the validation tools. Normally we're only to extend or add messages, not edit established protocol. Maybe a Linden closer to that code can comment. From moriz.gupte at gmail.com Thu May 7 08:48:11 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Thu, 7 May 2009 09:48:11 -0600 Subject: [sldev] Improving SL First Hour Experience through WYSIWIS Message-ID: Hello, Back in the days (http://portal.acm.org/citation.cfm?id=28056) It was clear then and is clear now that the opportunity to share views with peers in collaborative situations is of primary importance. CamSync is an example of one of the most useful HUDs in SL for orientation and teaching purposes and allows an avatar to see what another is looking at hence, What You See Is What I See. There are a few issues here though... view lag and choppiness... How about having an additional item on the piechart menu when u right click on an avatar to be 'Share view' The person who initiates this menu item 'Share view' will become the guide by default...'intent here is to reduce 'follow or guide menus' to a single item. I see this a great way to compensate for the lack of deixis (pointing cues...looking at micro facial gestures..gaze direction... head point etc...to infer point of interest) in SL due to inherent difficulties which prevent its successful implementation in the near future- I understand that there is a choice to be made between what residents and implement and what the client developers do, I think in this case, since a lot of new users will not know how to find the inventory in the first place, making this a client functionality is a plus. Sorry if this has been discussed earlier. Just think it deserves another look. R -- Rameshsharma Ramloll (Ramesh) Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2 , Blog: http://snipurl.com/3p5op , Play2Train: http://www.play2train.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090507/22d64d8a/attachment.htm From robla at lindenlab.com Thu May 7 09:54:30 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 07 May 2009 09:54:30 -0700 Subject: [sldev] Improving SL First Hour Experience through WYSIWIS In-Reply-To: References: Message-ID: <4A031246.3090905@lindenlab.com> This looks like a good topic for exploration on the sl-ux@ mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sl-ux Rob On 05/07/2009 08:48 AM, Moriz Gupte wrote: > Hello, > Back in the days (http://portal.acm.org/citation.cfm?id=28056) > It was clear then and is clear now that the opportunity to share views > with peers in collaborative situations is of primary importance. > CamSync is an example of one of the most useful HUDs in SL for > orientation and teaching purposes and allows an avatar to see what > another is looking at hence, What You See Is What I See. There are a > few issues here though... view lag and choppiness... > > How about having an additional item on the piechart menu when u right > click on an avatar to be 'Share view' > > The person who initiates this menu item 'Share view' will become the > guide by default...'intent here is to reduce 'follow or guide menus' > to a single item. I see this a great way to compensate for the lack of > deixis (pointing cues...looking at micro facial gestures..gaze > direction... head point etc...to infer point of interest) in SL due to > inherent difficulties which prevent its successful implementation in > the near future- > I understand that there is a choice to be made between what residents > and implement and what the client developers do, I think in this case, > since a lot of new users will not know how to find the inventory in > the first place, making this a client functionality is a plus. > Sorry if this has been discussed earlier. Just think it deserves > another look. > R > -- > Rameshsharma Ramloll (Ramesh) > Bio: http://snipurl.com/3p5ap , LinkedIn profile: > http://snipurl.com/3p5o2 , Blog: http://snipurl.com/3p5op , > Play2Train: http://www.play2train.org > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 schlenk at uni-oldenburg.de Thu May 7 12:02:41 2009 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Thu, 07 May 2009 21:02:41 +0200 Subject: [sldev] lltexturefetch race condition In-Reply-To: <4A0235AF.5060500@lindenlab.com> References: <4A0235AF.5060500@lindenlab.com> Message-ID: <4A033051.2010504@uni-oldenburg.de> Rob Lanphier schrieb: > In "Crash in lltexturefetch just after logging in" > https://jira.secondlife.com/browse/VWR-12775 > > Robin writes: >> Ok its a race condition between the >> LLTextureFetchWorker::callbackDecoded() and >> LLTextureFetchWorker::doWork() >> >> mState == DECODE_IMAGE kicks off the decode and sets the state machine >> to DECODE_IMAGE_UPDATE, this does nothing until the decoded flag is >> set, this is set in LLTextureFetchWorker::callbackDecoded(), but as >> soon as its set, the state machine moves on and in the event of a >> failed decode it sets mFormattedImage=NULL and sets the state machine >> back to INIT >> >> but in LLTextureFetchWorker::callbackDecoded we have already passed >> the check for STATE!=DECODE_IMAGE_UPDATE so the code moves on and then >> finds itsself for a NULL mFormattedImage >> >> Adding a 2nd >> >> if (mState != DECODE_IMAGE_UPDATE) >> >> { llwarns << "Decode callback for " << mID << " with state = " << >> mState << llendl; } >> >> after the >> >> mDecoded = TRUE; >> >> results in the 2nd warns message fireing every time mFormattedImage is >> null here, the first warns *BEFORE* mDecoded-TRUE never fires so its a >> race condition. >> > > Based on my reading of things, this comment may have been overlooked. The conclusion sounds correct. > Couple of questions: > 1. Does the comment above get us closer to a deeper fix for this problem? > 2. Should we go ahead and apply the attached patches for this, even if > they don't constitute a "real fix", because they do at least seem to > keep us from crashing? No crash is better than a crash. A real fix would simply not rely on the current logic to get at the image reference to decode some more or less unimportant info. If it would fetch the discardLevel right after the decode as it does with other info too and stash it somewhere for the callback to retrieve, the crash would go away. Not sure where one could stash the info though, but mFormattedImage is surely the wrong place. Michael From rdw at lindenlab.com Thu May 7 12:17:26 2009 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Thu, 07 May 2009 12:17:26 -0700 Subject: [sldev] Can message_template.msg be changed, or will that break third party applications? In-Reply-To: References: <20090507120604.GA29383@alinoe.com> Message-ID: <4A0333C6.8020508@lindenlab.com> On 5/7/09 5:45 AM, Soft wrote: > On Thu, May 7, 2009 at 7:06 AM, Carlo Wood wrote: > >> Is there a problem with changing app_settings/message_template.msg >> as I suggest here: >> >> http://jira.secondlife.com/browse/VWR-13267 >> >> that I'm overlooking? >> > > On the server, it reads it as a U8, but it's only using it to feed > methods that want BOOLs. This really should have been a BOOL, as you > point out. Since BOOL and U8 are the same size, it may be okay to > change this over and to change the server code to unpack a BOOL to > avoid introducing a warning there. > > I'm not sure how much havoc this change would wreak with the > validation tools. Normally we're only to extend or add messages, not > edit established protocol. Maybe a Linden closer to that code can > comment. > I commented, though I'm pretty far from that code these days. I think as a practical matter of getting the code released it's better to just convert the viewer to cast the bool to a U8 and pack that. The validation tools would be complaining for months both before and after this change, possibly years, and would increase the risk that a really-breaking change would sneak through amongst all the false positives. From merov at lindenlab.com Thu May 7 19:00:40 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 7 May 2009 19:00:40 -0700 Subject: [sldev] http-texture svn 2230 Message-ID: <02686A4C-5014-48FA-8697-E1A993EF585B@lindenlab.com> Hi, I moved forward and merged the 1.23 RC0 + http-texture latest in / projects/2009/http-texture. Builds went through but Parabuild has not giving me the S3 result location yet (not sure why it takes that long... CG?...). We should have clean builds shortly. Cheers - Merov From merov at lindenlab.com Thu May 7 19:10:39 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 7 May 2009 19:10:39 -0700 Subject: [sldev] VWR-12775 : Race condition avoidance patch Message-ID: <0BE0481C-6E30-456D-BB19-4C9ABC6783A2@lindenlab.com> Hi guys, That one is such a sucker! I spent some time on it this afternoon and, reading back through Robin's comment and using my recently gained understanding of the llimageworker thread (acquired through the writing of llimageworker_test... hurray for unit tests!... :) ) I think I have a solution to that bug. At least, I wasn't able to repro the crash at all as might as I tried. I committed the patch (svn 2232) but *did not* triggered the builds so that it gives you time to look into it and weight on the JIRA. Everything is in place to trigger the builds and, if you really don't like it, we can always roll that one back (it's a 1 liner). Let me know what you think. Special thanks BTW on that one to Robin, Khyota, Techwolf and Michael for their help (we're not done yet though guys :) ) Cheers, - Merov From tigrospottystripes at gmail.com Thu May 7 21:19:42 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 08 May 2009 01:19:42 -0300 Subject: [sldev] would this help with increasing the apparent number of light sources at all? Message-ID: <4A03B2DE.8030602@Gmail.com> http://gpwiki.org/index.php/OpenGL:Tutorials:Virtualized_Lights_with_OpenGL_and_GLSL I stumbled upon this while googling for somthing else, I don't have enough knowledge to actually understand the code there, would the technique described in that page help with allowing a bigger number of apparent light sources in SL ? (I know the limit OpenGL imposes, that technique seems to be able to make it look like there are more light sources than OpenGL allows) From danteferret at gmail.com Thu May 7 21:47:45 2009 From: danteferret at gmail.com (danteferret at gmail.com) Date: Fri, 08 May 2009 04:47:45 +0000 Subject: [sldev] would this help with increasing the apparent number of light sources at all? In-Reply-To: <4A03B2DE.8030602@Gmail.com> Message-ID: <0016361645a5633eaa04695f54de@google.com> Theres already a system for infinite light sources in the shadow-draft client. Why not just use that minus shadows? I have been meaning to ask this for a long time. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090508/1cb54fa4/attachment.htm From melinda at superliminal.com Fri May 8 01:50:22 2009 From: melinda at superliminal.com (Melinda Green) Date: Fri, 08 May 2009 01:50:22 -0700 Subject: [sldev] Improving SL First Hour Experience through WYSIWIS In-Reply-To: References: Message-ID: <4A03F24E.70300@superliminal.com> Wow, that was a while ago! I've not seen or heard of this HUD and while it sounds like it has merit, it also sounds somewhat invasive. I have a personal, almost physical relationship with my camera and I doubt I would like that. I expect that I would not like losing the ability to cam around, adjust my view, and check out people's profiles, etc. I expect that being driven by it would feel as if someone else was grabbing my head and moving it around. I think that I would much prefer other sorts of pointing devices. Even if this mode is useful I doubt that it'd be popular enough to permanently add to the viewer. HUDs are perfect for this sort of niche functionality so I would much rather see effort made to figure out what is causing those lag and choppiness issues you're reporting. I also don't see how this would help newbies to find their inventory, etc. since this certainly would not let one person see the other person's UI, right? -Melinda Moriz Gupte wrote: > Hello, > Back in the days (http://portal.acm.org/citation.cfm?id=28056) > It was clear then and is clear now that the opportunity to share views > with peers in collaborative situations is of primary importance. > CamSync is an example of one of the most useful HUDs in SL for > orientation and teaching purposes and allows an avatar to see what > another is looking at hence, What You See Is What I See. There are a > few issues here though... view lag and choppiness... > > How about having an additional item on the piechart menu when u right > click on an avatar to be 'Share view' > > The person who initiates this menu item 'Share view' will become the > guide by default...'intent here is to reduce 'follow or guide menus' > to a single item. I see this a great way to compensate for the lack of > deixis (pointing cues...looking at micro facial gestures..gaze > direction... head point etc...to infer point of interest) in SL due to > inherent difficulties which prevent its successful implementation in > the near future- > I understand that there is a choice to be made between what residents > and implement and what the client developers do, I think in this case, > since a lot of new users will not know how to find the inventory in > the first place, making this a client functionality is a plus. > Sorry if this has been discussed earlier. Just think it deserves > another look. > R > -- > Rameshsharma Ramloll (Ramesh) > Bio: http://snipurl.com/3p5ap , LinkedIn profile: > http://snipurl.com/3p5o2 , Blog: http://snipurl.com/3p5op , > Play2Train: http://www.play2train.org > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 mrfrans at gmail.com Fri May 8 07:54:30 2009 From: mrfrans at gmail.com (Frans) Date: Fri, 8 May 2009 16:54:30 +0200 Subject: [sldev] Improving SL First Hour Experience through WYSIWIS In-Reply-To: <4A03F24E.70300@superliminal.com> References: <4A03F24E.70300@superliminal.com> Message-ID: <7765f2c60905080754t2c4ff17cn7021a170ed54a74f@mail.gmail.com> I personally like the idea of being able to temporally have other people follow your camera, especially when I'm trying to explain something and there is confusion about what I'm talking. Similarly the other way around so I can see what they see. It would have to be really straight forward and obvious though if it is build in. I would want a 'instant replay' type icon on the screen so there is a constant reminder for people that they are not in control of their camera. The interface of gaining control back should be obvious too. I believe we have currently a 'release camera' button when your camera is under script control, but I'm not sure it is noticeable enough amongst the the other buttons. Early on when the script functions to follow the camera where first released I made some toys, prim cameras and arrows that follow you camera, in that way providing a visual mark to show people where you are looking without taking control of their cam. I think for most uses that might be sufficient, though. @Melinda, you are correct the camera will only be able to be moved in 3D space and wouldn't be able to show where the inventory button is. Unless you zoom in on a picture(on a prim) of the inventory button. But in that case you can just as well use a pointing arrow. On Fri, May 8, 2009 at 10:50 AM, Melinda Green wrote: > Wow, that was a while ago! > > I've not seen or heard of this HUD and while it sounds like it has > merit, it also sounds somewhat invasive. I have a personal, almost > physical relationship with my camera and I doubt I would like that. I > expect that I would not like losing the ability to cam around, adjust my > view, and check out people's profiles, etc. I expect that being driven > by it would feel as if someone else was grabbing my head and moving it > around. I think that I would much prefer other sorts of pointing devices. > > Even if this mode is useful I doubt that it'd be popular enough to > permanently add to the viewer. HUDs are perfect for this sort of niche > functionality so I would much rather see effort made to figure out what > is causing those lag and choppiness issues you're reporting. > > I also don't see how this would help newbies to find their inventory, > etc. since this certainly would not let one person see the other > person's UI, right? > > -Melinda -- Jeroen Frans Virtual World Technology Specialist. TheVesuviusGroup.com SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090508/5bc7b37e/attachment.htm From ron at involve3d.com Fri May 8 08:22:02 2009 From: ron at involve3d.com (Ron Blechner) Date: Fri, 8 May 2009 11:22:02 -0400 Subject: [sldev] Improving SL First Hour Experience through WYSIWIS In-Reply-To: <7765f2c60905080754t2c4ff17cn7021a170ed54a74f@mail.gmail.com> References: <4A03F24E.70300@superliminal.com> <7765f2c60905080754t2c4ff17cn7021a170ed54a74f@mail.gmail.com> Message-ID: I think there's a more meta question here: How successful have HUDs been with new user experience? I have blogged before about the idea of a need for a "look-at" pie-menu option: http://secondtense.blogspot.com/2009/03/basic-functions-second-life-needs.html ... and in general, I think there's room to improve camera function. I've also previously in the past experimented with BijoCam, a hud-based interface that interacts with invisible tripwires to trigger 3rd person remote camera setups. It's a bit bewildering at first, because we're used to the over-the-shoulder control, not a third person Alone-In-The-Dark (it's the earliest example I can think of) control, but I also found the longer I was in it, the easier it became. At the same time, that was not useful at all with learning SL's default control. Thus, when discussing HUD-based teaching systems for new-user experience, I'm concerned about users getting used to having their camera controlled, and then suddenly when they're in the rest of SL, it never happening --- essentially it teaches new skills and sets new expectations that are not present in the rest of the Second Life platform. No, and this is why I lean with Frans' sentiment that the bigger issue isn't HUDs, but with the SL client itself. I would love, for example, to shove the camera permissions - which need to be granted via pop-up blue floater for EVERY script wanting to take control - into the browser itself. It would require basically putting camera-control permissions into avatar-level permissions. (i.e. Muting, see online, etc) Some intuitive default settings would be: - Camera control granted for avatar / objects of landowner of parcel your avatar inhabits. - Camera control granted for friends. - Camera control granted for Linden accounts. - Camera control disabled for all others. Additionally, I think in order for this to be easily usable, it would need to be non-scripted. There would need to be a floater that is somewhere in the UI that integrates with the "Look at" ... where maybe you click a button to "set a camera target" and then click on the object, at which point in time it calculates the proper camera-eye location and camera-target location and sets it to the floater's local data. Then a "show avatar" button where you could then basically create a hyperlink in chat where people would click on the link and it would control their camera. ... This is all, of course, a tall order. In the long run, I see many benefits of it. I know people will say that what I'm suggesting is far too much work, but what I'm essentially saying is that the system won't be intuitive enough otherwise - including HUD-based solutions. Regards, Ron -- Ron Blechner Chief Technology Officer Involve, Inc www.involve3d.com SL: Hiro Pendragon On Fri, May 8, 2009 at 10:54 AM, Frans wrote: > I?personally?like the idea of being able to?temporally?have other people > follow your camera, especially when I'm trying to explain something and > there is confusion about what I'm talking.?Similarly?the other way around so > I can see what they see. > It would have to be really straight forward and obvious though if it is > build in. I would want a 'instant replay' type icon on the screen so there > is a constant reminder for people that they are not in control of their > camera. The interface of gaining control back should be obvious too. I > believe we have currently a 'release camera' button when your camera is > under script control, but I'm not sure it is noticeable enough amongst the > the other buttons. > Early on when the script functions to follow the camera where first released > I made some toys, prim cameras and arrows that follow you camera, in that > way providing a visual mark to show people where you are looking without > taking control of their cam. I think for most uses that might be sufficient, > though. > @Melinda, you are correct the camera will only be able to be moved in 3D > space and wouldn't be able to show where the inventory button is. Unless you > zoom in on a picture(on a prim) of the inventory button. But in that case > you can just as well use a pointing arrow. > > On Fri, May 8, 2009 at 10:50 AM, Melinda Green > wrote: >> >> Wow, that was a while ago! >> >> I've not seen or heard of this HUD and while it sounds like it has >> merit, it also sounds somewhat invasive. I have a personal, almost >> physical relationship with my camera and I doubt I would like that. I >> expect that I would not like losing the ability to cam around, adjust my >> view, and check out people's profiles, etc. I expect that being driven >> by it would feel as if someone else was grabbing my head and moving it >> around. I think that I would much prefer other sorts of pointing devices. >> >> Even if this mode is useful I doubt that it'd be popular enough to >> permanently add to the viewer. HUDs are perfect for this sort of niche >> functionality so I would much rather see effort made to figure out what >> is causing those lag and choppiness issues you're reporting. >> >> I also don't see how this would help newbies to find their inventory, >> etc. since this certainly would not let one person see the other >> person's UI, right? >> >> -Melinda > > > -- > Jeroen Frans > Virtual World Technology Specialist. > TheVesuviusGroup.com > SL: Frans Charming > > _______________________________________________ > 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 May 8 09:48:36 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 08 May 2009 09:48:36 -0700 Subject: [sldev] VWR-12775 : Race condition avoidance patch In-Reply-To: <0BE0481C-6E30-456D-BB19-4C9ABC6783A2@lindenlab.com> References: <0BE0481C-6E30-456D-BB19-4C9ABC6783A2@lindenlab.com> Message-ID: <4A046264.6020300@lindenlab.com> On 05/07/2009 07:10 PM, Philippe Bossut (Merov Linden) wrote: > That one is such a sucker! I spent some time on it this afternoon and, > reading back through Robin's comment and using my recently gained > understanding of the llimageworker thread (acquired through the > writing of llimageworker_test... hurray for unit tests!... :) ) I > think I have a solution to that bug. At least, I wasn't able to repro > the crash at all as might as I tried. > > I committed the patch (svn 2232) but *did not* triggered the builds so > that it gives you time to look into it and weight on the JIRA. > Everything is in place to trigger the builds and, if you really don't > like it, we can always roll that one back (it's a 1 liner). > > Let me know what you think. > > Special thanks BTW on that one to Robin, Khyota, Techwolf and Michael > for their help (we're not done yet though guys :) ) > Hmmm....I've got no ideas about the merits of the change, which look pretty conservative: http://svn.secondlife.com/trac/linden/changeset/2232 However, based on the behavior I'm seeing with the newly built viewers (I kicked off a build this morning), it doesn't work. I still crash on startup unless I clear my cache first. Build links for the latest build are available below. Rob -------- Original Message -------- Subject: [sldev-commits] Successful Build for http-texture (2232) Date: Fri, 8 May 2009 09:14:44 -0700 (PDT) From: buildadmin at lindenlab.com To: sldev-commits at lists.secondlife.com Linux: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/SecondLife-i686-1.23.0.2232.tar.bz2 http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/good-build.Linux Darwin: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/SecondLife_1_23_0_2232_OSS.dmg http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/good-build.Darwin CYGWIN: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/Second_Life_1-23-0-2232_OSS_Setup.exe http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/good-build.CYGWIN ------------------------------------------------------------------------ r2230 | merov.linden | 2009-05-07 17:30:22 -0700 (Thu, 07 May 2009) | 2 lines Changed paths: M /projects/2009/http-texture M /projects/2009/http-texture/doc/asset_urls.txt M /projects/2009/http-texture/doc/contributions.txt M /projects/2009/http-texture/indra/llcommon/llversionserver.h M /projects/2009/http-texture/indra/llcommon/llversionviewer.h M /projects/2009/http-texture/indra/llimage/CMakeLists.txt M /projects/2009/http-texture/indra/llimage/llimageworker.cpp M /projects/2009/http-texture/indra/llimage/llimageworker.h M /projects/2009/http-texture/indra/newview/CMakeLists.txt M /projects/2009/http-texture/indra/newview/English.lproj/InfoPlist.strings M /projects/2009/http-texture/indra/newview/Info-SecondLife.plist M /projects/2009/http-texture/indra/newview/installers/windows/installer_template.nsi M /projects/2009/http-texture/indra/newview/llagent.cpp M /projects/2009/http-texture/indra/newview/llappviewer.cpp M /projects/2009/http-texture/indra/newview/llfloatersnapshot.cpp M /projects/2009/http-texture/indra/newview/llpanelclassified.cpp A /projects/2009/http-texture/indra/newview/lltexturestats.cpp (from /branches/2009/http-texture/indra/newview/lltexturestats.cpp:2229) A /projects/2009/http-texture/indra/newview/lltexturestats.h (from /branches/2009/http-texture/indra/newview/lltexturestats.h:2229) M /projects/2009/http-texture/indra/newview/llviewermessage.cpp M /projects/2009/http-texture/indra/newview/llviewerstats.cpp M /projects/2009/http-texture/indra/newview/llviewerstats.h M /projects/2009/http-texture/indra/newview/res/viewerRes.rc M /projects/2009/http-texture/indra/newview/skins/default/xui/en-us/floater_preview_existing_landmark.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/en-us/panel_avatar_classified.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/en-us/panel_classified.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/en-us/panel_group_general.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/en-us/panel_preferences_general.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/en-us/panel_preferences_voice.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/es/floater_about.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/es/floater_chat_history.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/es/panel_preferences_audio.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/es/panel_preferences_chat.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/es/panel_preferences_general.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/ko/floater_about.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/ko/floater_chat_history.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/pl/floater_about.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/pl/floater_buy_land.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/pl/floater_chat_history.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/pt/floater_about.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/pt/floater_chat_history.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/pt/panel_preferences_audio.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/ru/floater_about.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/ru/floater_chat_history.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/uk/floater_chat_history.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/zh/floater_about.xml M /projects/2009/http-texture/indra/newview/skins/default/xui/zh/floater_chat_history.xml M /projects/2009/http-texture/install.xml svn merge -r2162:2229 https://svn.secondlife.com/svn/linden/branches/2009/http-texture Update to newest (1.23 RC0 + http-texture) ------------------------------------------------------------------------ r2232 | merov.linden | 2009-05-07 18:52:21 -0700 (Thu, 07 May 2009) | 1 line Changed paths: M /projects/2009/http-texture/indra/newview/lltexturefetch.cpp VWR-12775 : race condition avoidance on decode callback (1 liner). Tested but not reviewed yet! ------------------------------------------------------------------------ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits From merov at lindenlab.com Fri May 8 10:24:09 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Fri, 8 May 2009 10:24:09 -0700 Subject: [sldev] VWR-12775 : Race condition avoidance patch In-Reply-To: <4A046264.6020300@lindenlab.com> References: <0BE0481C-6E30-456D-BB19-4C9ABC6783A2@lindenlab.com> <4A046264.6020300@lindenlab.com> Message-ID: <8A5C77BD-01F6-45DD-88CD-EC4F0C6D5B46@lindenlab.com> Hi Rob, K, I'm pretty sure it fixes one cause of crashes but not all of them. That being said, I'd like to see the crash logs of your crash. I'll dig through the crash logger to see if I find something there. Thanks for kicking the build this morning. Cheers, - Merov On May 8, 2009, at 9:48 AM, Rob Lanphier wrote: > On 05/07/2009 07:10 PM, Philippe Bossut (Merov Linden) wrote: >> That one is such a sucker! I spent some time on it this afternoon >> and, >> reading back through Robin's comment and using my recently gained >> understanding of the llimageworker thread (acquired through the >> writing of llimageworker_test... hurray for unit tests!... :) ) I >> think I have a solution to that bug. At least, I wasn't able to repro >> the crash at all as might as I tried. >> >> I committed the patch (svn 2232) but *did not* triggered the builds >> so >> that it gives you time to look into it and weight on the JIRA. >> Everything is in place to trigger the builds and, if you really don't >> like it, we can always roll that one back (it's a 1 liner). >> >> Let me know what you think. >> >> Special thanks BTW on that one to Robin, Khyota, Techwolf and Michael >> for their help (we're not done yet though guys :) ) >> > > Hmmm....I've got no ideas about the merits of the change, which look > pretty conservative: > http://svn.secondlife.com/trac/linden/changeset/2232 > > However, based on the behavior I'm seeing with the newly built viewers > (I kicked off a build this morning), it doesn't work. I still crash on > startup unless I clear my cache first. > > Build links for the latest build are available below. > > Rob > > -------- Original Message -------- > Subject: [sldev-commits] Successful Build for http-texture (2232) > Date: Fri, 8 May 2009 09:14:44 -0700 (PDT) > From: buildadmin at lindenlab.com > To: sldev-commits at lists.secondlife.com > > > > Linux: > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/SecondLife-i686-1.23.0.2232.tar.bz2 > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/good-build.Linux > > Darwin: > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/SecondLife_1_23_0_2232_OSS.dmg > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/good-build.Darwin > > CYGWIN: > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/Second_Life_1-23-0-2232_OSS_Setup.exe > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/good-build.CYGWIN > > ------------------------------------------------------------------------ > r2230 | merov.linden | 2009-05-07 17:30:22 -0700 (Thu, 07 May 2009) > | 2 lines > Changed paths: > M /projects/2009/http-texture > M /projects/2009/http-texture/doc/asset_urls.txt > M /projects/2009/http-texture/doc/contributions.txt > M /projects/2009/http-texture/indra/llcommon/llversionserver.h > M /projects/2009/http-texture/indra/llcommon/llversionviewer.h > M /projects/2009/http-texture/indra/llimage/CMakeLists.txt > M /projects/2009/http-texture/indra/llimage/llimageworker.cpp > M /projects/2009/http-texture/indra/llimage/llimageworker.h > M /projects/2009/http-texture/indra/newview/CMakeLists.txt > M /projects/2009/http-texture/indra/newview/English.lproj/ > InfoPlist.strings > M /projects/2009/http-texture/indra/newview/Info-SecondLife.plist > M /projects/2009/http-texture/indra/newview/installers/windows/ > installer_template.nsi > M /projects/2009/http-texture/indra/newview/llagent.cpp > M /projects/2009/http-texture/indra/newview/llappviewer.cpp > M /projects/2009/http-texture/indra/newview/llfloatersnapshot.cpp > M /projects/2009/http-texture/indra/newview/llpanelclassified.cpp > A /projects/2009/http-texture/indra/newview/lltexturestats.cpp > (from /branches/2009/http-texture/indra/newview/lltexturestats.cpp: > 2229) > A /projects/2009/http-texture/indra/newview/lltexturestats.h > (from /branches/2009/http-texture/indra/newview/lltexturestats.h:2229) > M /projects/2009/http-texture/indra/newview/llviewermessage.cpp > M /projects/2009/http-texture/indra/newview/llviewerstats.cpp > M /projects/2009/http-texture/indra/newview/llviewerstats.h > M /projects/2009/http-texture/indra/newview/res/viewerRes.rc > M /projects/2009/http-texture/indra/newview/skins/default/xui/en- > us/floater_preview_existing_landmark.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/en- > us/panel_avatar_classified.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/en- > us/panel_classified.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/en- > us/panel_group_general.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/en- > us/panel_preferences_general.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/en- > us/panel_preferences_voice.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/es/ > floater_about.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/es/ > floater_chat_history.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/es/ > panel_preferences_audio.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/es/ > panel_preferences_chat.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/es/ > panel_preferences_general.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/ko/ > floater_about.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/ko/ > floater_chat_history.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/pl/ > floater_about.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/pl/ > floater_buy_land.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/pl/ > floater_chat_history.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/pt/ > floater_about.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/pt/ > floater_chat_history.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/pt/ > panel_preferences_audio.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/ru/ > floater_about.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/ru/ > floater_chat_history.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/uk/ > floater_chat_history.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/zh/ > floater_about.xml > M /projects/2009/http-texture/indra/newview/skins/default/xui/zh/ > floater_chat_history.xml > M /projects/2009/http-texture/install.xml > > svn merge -r2162:2229 https://svn.secondlife.com/svn/linden/branches/2009/http-texture > Update to newest (1.23 RC0 + http-texture) > ------------------------------------------------------------------------ > r2232 | merov.linden | 2009-05-07 18:52:21 -0700 (Thu, 07 May 2009) > | 1 line > Changed paths: > M /projects/2009/http-texture/indra/newview/lltexturefetch.cpp > > VWR-12775 : race condition avoidance on decode callback (1 liner). > Tested but not reviewed yet! > ------------------------------------------------------------------------ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits > > > > > From poppy at lindenlab.com Fri May 8 12:30:56 2009 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Fri, 08 May 2009 12:30:56 -0700 Subject: [sldev] SLDev Viewer--code review In-Reply-To: <383413B3-BBB4-452B-8EA5-24CBE02EE4D6@lindenlab.com> References: <4A01C9BC.6020105@watson.ibm.com> <383413B3-BBB4-452B-8EA5-24CBE02EE4D6@lindenlab.com> Message-ID: <4A048870.2060601@lindenlab.com> I'm happy to review messaging, cmake, http, or other misc infrastructure patches. Email, IM (sl, AIM, or skype) and we can voice (sl or skype) mid-late day PST (early in the day for asia ;) ideally you have a shell session using screen I can hop in as, or something of that nature. + poppy Philippe Bossut (Merov Linden) wrote: > Hi, > > I've been ruminating that one, especially the "live" aspect of it. > When it was proposed during the Hippo gathering I immediately said > "why not?". Reading Mike's writing though, I'm wondering. Some > elements of reflection: > - Code reviews are good: I personally learned a lot along the years > every time I was able to sit down with someone and go through code > line by line, being my code or the one of others. > - Committees are bad: That being said, doing this in a committee (i.e. > 3 persons or more) is incredibly inefficient, unless the people know > each other really well. The human psychology usually moves the > objective of such gathering from "let's raise a barn together" to > "who's the king of the hill". Terrible. > - Live chat with others about code with some code in hand is a good > idea: Coming up to someone with a problem and chatting about it often > steers you in the right direction. And I'm a chatterbox so that suit > me really well but others might feel differently and shouldn't be > pushed out as a result. > - One can't ignore RL realities: A formal process imposing real time > constraints will leave part of the planet out (time zone conflicts). > *Speaking* English will also be challenging for lots of us (reading > and typing is easier). I for one am not a native english speaker and > though I'm doing well now with English (despite a horrendous French > accent), I do empathize with those who don't. In short, I'm wary of > making a formal real time voice enabled presentation a requirement. > > With all that in hand. here's my stand on the subject: > - "Formal" (format TBD) code review need to happen on the list and/or > JIRA in writing: i.e. in the open, asynchronously, trackable. This is > how I've seen it done in other projects. > - Contributors *should* whenever possible get the help of others on > IRC and/or IW in ad-hoc sessions with a reviewer. Definitely, I hear > Mike's pledge for voice IW interaction. I miss it and I think it'll > help us get to know each other and smooth the kinks in that group. > Having an office hour of sort for some of us would make sense for > instance. I'd be willing to have one and see how it works. Any takers? > > Cheers, > - Merov > > On May 6, 2009, at 10:32 AM, Mike Monkowski wrote: > >> I haven't heard any feedback on the preliminary page describing the >> SLDev Open Source Viewer project at >> http://wiki.secondlife.com/wiki/User:Mm_Alder/SLDev_Open_Source_Viewer >> but there's a lot to read there, so maybe people were scared away by >> its >> length, but I would particularly be interested in hearing comments on >> the code review section: >> >>> OK, so I'm completely making this part up, but this is the way I >>> think it should happen. >>> >>> Every week open source developers and Lindens gather at a miniature >>> Roman Coliseum on Hippotropolis. >>> >>> Contributors have added their names to a list on the wiki together >>> with a link pointing to the PJIRA issue that describes their >>> contributions and includes a patch file made against the current >>> version of the SLDev open source. One by one the contributors are >>> called before the Linden tribunal. Using voice chat and an in-world >>> display showing the code with highlights on the changes, the >>> contributor describes what that part of the code used to do and how >>> this contribution makes it better. Developers politely ask >>> questions using text chat, and the contributor answers them in turn. >>> >>> In the end, everyone learns something, and if the code is deemed >>> worthy, the contribution is given a thumbs up approval. If not, >>> lions. Or at least a second chance. >>> >>> Well that's the way I think it should work, except for the lions. >> Is this technically feasible in SL? If such a gathering were to take >> place, would anyone show up? I see it as a way to build a community, >> learn the viewer code, and get changes implemented. I think it would >> make life easier for reviewers as well. Anybody else see it this way? >> Or would it just be a waste of time? Does the mention of "voice chat" >> doom it from its inception? >> >> Mike >> Mm Alder >> _______________________________________________ >> 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 brad at lindenlab.com Fri May 8 13:19:17 2009 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Fri, 08 May 2009 16:19:17 -0400 Subject: [sldev] ZLib and Boost In-Reply-To: <3bb9647e0905062311t1e47c399p16b072ee9dd3d092@mail.gmail.com> References: <3bb9647e0905062311t1e47c399p16b072ee9dd3d092@mail.gmail.com> Message-ID: <4A0493C5.8010308@lindenlab.com> Oops, I think you got tripped up by a change we recently made to trunk for building our 32 bit viewers on 64 bit machines. I meant to announce this here ahead of time, but it slipped through the cracks. I think anyone doing standalone builds on 64 bit distributions will get the same errors. There is now a new (as of r2201 i think) optional argument to develop.py (and equivalently a new cmake variable) to configure whether you are building 32bit or 64bit code, and it defaults to 32bit. If you want to build a 64bit viewer you probably want to configure using something like the following: ./develop.py -m64 --standalone configure If you want to build a 32bit viewer, you'll need your distro's 32bit development libs installed (on debian it's called libc6-dev-i386 and I additionally needed libglu1-mesa-dev) and you'll either need to do a non-standalone build, or build 32bit versions of all third party libs. If you're not using develop.py and running cmake by hand you'll need to pass -DWORD_SIZE=64 as an extra argument to cmake to override the default. apologies for the surprise, -Brad Ricky wrote: > Have the version requirements for zlib and boost changed recently (as > in within the last 3 months)? > > I get the following error on compile, and the last time I compiled, > (April 16 according to my logs,) it ran just fine... > > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: > skipping incompatible /lib64/libz.so when searching for -lz > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: > skipping incompatible /lib64/libz.so when searching for -lz > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: > skipping incompatible > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../libboost_signals-mt.so > when searching for -lboost_signals-mt > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: > skipping incompatible /usr/lib/libboost_signals-mt.so when searching > for -lboost_signals-mt > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: > cannot find -lboost_signals-mt > collect2: ld returned 1 exit status > > I'm compiling against trunk, revision 2227. (Latest edition as of this > writing.) > > Thanks, > 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 From robla at lindenlab.com Fri May 8 14:04:43 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 08 May 2009 14:04:43 -0700 Subject: [sldev] Open issues remaining on a first release Message-ID: <4A049E6B.4020902@lindenlab.com> Hi everyone, You may have noticed that we have a list of issues to get through on this page: https://wiki.secondlife.com/wiki/SLDev_Viewer_Current_Cycle We had a great conversation about this at the OSS meeting yesterday: https://wiki.secondlife.com/wiki/Open_Source_Meeting/2009-05-07 Here's where we stand with the various issues: > * Mm Alder's babble loop beta->default: VWR-10311 > o Status: Awaiting patch for VWR-13260 to enable a preference We're not sure when we'll be closing down the merge window, but almost certainly no later than June 12, and hopefully sooner than that. So, we'll need a patch for VWR-13260 before then in order for this one to make it in. > * easybuild: VWR-12758 > o Status: TBD Don't want to get too deep on this one while Brad is still out. I'd really like everyone to give the easybuild-2 branch a try, since that has the http-texture changes merged in. > * Patch to make branding changes simpler > o Soliciting patches - see VWR-13295 My next chore is to get VWR-13295 cleaned up a little bit more, and take a deeper look at the issue myself. > * Change branding > o Status: Awaiting guidance from Linden Lab Waiting for some gears to turn on this one. Soon we hope.... > * Change standard font to DejaVu Sans > o Soliciting patches Based on the conversation yesterday, combined with the fact that there's a UI redesign in the works, we think it's probably not smart for us to tackle this one just yet. So, rather than putting something in JIRA, we'll probably just punt on this. > * LLTextureFetch crash: key issue is nullification of > mFormattedImage pointer between 2 threads. Merov on track to fix. > o VWR-12775: Crash in lltexturefetch just after logging in > (DEV-30500 in LL tracker) Merov is working on this this afternoon, and should have the workaround checked in this afternoon. > * Curl crash: spurious crash, no repro steps: VWR-12952 Still need to fix this one, I think. Rob From merov at lindenlab.com Fri May 8 16:29:32 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Fri, 8 May 2009 16:29:32 -0700 Subject: [sldev] VWR-12775 : Race condition avoidance patch In-Reply-To: <8A5C77BD-01F6-45DD-88CD-EC4F0C6D5B46@lindenlab.com> References: <0BE0481C-6E30-456D-BB19-4C9ABC6783A2@lindenlab.com><4A046264.6020300@lindenlab.com> <8A5C77BD-01F6-45DD-88CD-EC4F0C6D5B46@lindenlab.com> Message-ID: <0D32640D-19A9-4A1B-A4DE-DFEF9238F551@lindenlab.com> Hi, Well, the patch didn't have the expected result so, in order to see if patching the problematic responder helps, I committed the old patch (svn 2235) on top of the change I committed yesterday. Builds are under way and should be available in a short while (Mac and Linux already completed successfully and I'm expecting Windows to clear up soon). I'll post again when URLs become available. We'll see if that bring the crash rate down a bit. Discussing with steve this afternoon, he agreed that the best we should be doing to improve the reliability of that new code base is to put most of it under unit test and document it. I did some of it last week, adding unit tests to llimage/llimageworker.cpp. Las, I realized that I forgot to modify the export script so the unit tests never made it to branches/http-texture. I fixed that with CG this afternoon and, next export, we should get them. Writing unit tests is finicky so it's better to start with some example and doc. I've been working with poppy to bring some doc to the public wiki. Stay tune for coming links on the subject. Cheers, - Merov On May 8, 2009, at 10:24 AM, Philippe Bossut (Merov Linden) wrote: > Hi Rob, > > K, I'm pretty sure it fixes one cause of crashes but not all of them. > That being said, I'd like to see the crash logs of your crash. I'll > dig through the crash logger to see if I find something there. > > Thanks for kicking the build this morning. > > Cheers, > - Merov > > On May 8, 2009, at 9:48 AM, Rob Lanphier wrote: > >> On 05/07/2009 07:10 PM, Philippe Bossut (Merov Linden) wrote: >>> That one is such a sucker! I spent some time on it this afternoon >>> and, >>> reading back through Robin's comment and using my recently gained >>> understanding of the llimageworker thread (acquired through the >>> writing of llimageworker_test... hurray for unit tests!... :) ) I >>> think I have a solution to that bug. At least, I wasn't able to >>> repro >>> the crash at all as might as I tried. >>> >>> I committed the patch (svn 2232) but *did not* triggered the builds >>> so >>> that it gives you time to look into it and weight on the JIRA. >>> Everything is in place to trigger the builds and, if you really >>> don't >>> like it, we can always roll that one back (it's a 1 liner). >>> >>> Let me know what you think. >>> >>> Special thanks BTW on that one to Robin, Khyota, Techwolf and >>> Michael >>> for their help (we're not done yet though guys :) ) >>> >> >> Hmmm....I've got no ideas about the merits of the change, which look >> pretty conservative: >> http://svn.secondlife.com/trac/linden/changeset/2232 >> >> However, based on the behavior I'm seeing with the newly built >> viewers >> (I kicked off a build this morning), it doesn't work. I still crash >> on >> startup unless I clear my cache first. >> >> Build links for the latest build are available below. >> >> Rob >> >> -------- Original Message -------- >> Subject: [sldev-commits] Successful Build for http-texture (2232) >> Date: Fri, 8 May 2009 09:14:44 -0700 (PDT) >> From: buildadmin at lindenlab.com >> To: sldev-commits at lists.secondlife.com >> >> >> >> Linux: >> http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/SecondLife-i686-1.23.0.2232.tar.bz2 >> http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/good-build.Linux >> >> Darwin: >> http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/SecondLife_1_23_0_2232_OSS.dmg >> http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/good-build.Darwin >> >> CYGWIN: >> http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/Second_Life_1-23-0-2232_OSS_Setup.exe >> http://secondlife.com/developers/opensource/downloads/2009/http-texture/2232/good-build.CYGWIN >> >> ------------------------------------------------------------------------ >> r2230 | merov.linden | 2009-05-07 17:30:22 -0700 (Thu, 07 May 2009) >> | 2 lines >> Changed paths: >> M /projects/2009/http-texture >> M /projects/2009/http-texture/doc/asset_urls.txt >> M /projects/2009/http-texture/doc/contributions.txt >> M /projects/2009/http-texture/indra/llcommon/llversionserver.h >> M /projects/2009/http-texture/indra/llcommon/llversionviewer.h >> M /projects/2009/http-texture/indra/llimage/CMakeLists.txt >> M /projects/2009/http-texture/indra/llimage/llimageworker.cpp >> M /projects/2009/http-texture/indra/llimage/llimageworker.h >> M /projects/2009/http-texture/indra/newview/CMakeLists.txt >> M /projects/2009/http-texture/indra/newview/English.lproj/ >> InfoPlist.strings >> M /projects/2009/http-texture/indra/newview/Info-SecondLife.plist >> M /projects/2009/http-texture/indra/newview/installers/windows/ >> installer_template.nsi >> M /projects/2009/http-texture/indra/newview/llagent.cpp >> M /projects/2009/http-texture/indra/newview/llappviewer.cpp >> M /projects/2009/http-texture/indra/newview/llfloatersnapshot.cpp >> M /projects/2009/http-texture/indra/newview/llpanelclassified.cpp >> A /projects/2009/http-texture/indra/newview/lltexturestats.cpp >> (from /branches/2009/http-texture/indra/newview/lltexturestats.cpp: >> 2229) >> A /projects/2009/http-texture/indra/newview/lltexturestats.h >> (from /branches/2009/http-texture/indra/newview/lltexturestats.h: >> 2229) >> M /projects/2009/http-texture/indra/newview/llviewermessage.cpp >> M /projects/2009/http-texture/indra/newview/llviewerstats.cpp >> M /projects/2009/http-texture/indra/newview/llviewerstats.h >> M /projects/2009/http-texture/indra/newview/res/viewerRes.rc >> M /projects/2009/http-texture/indra/newview/skins/default/xui/en- >> us/floater_preview_existing_landmark.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/en- >> us/panel_avatar_classified.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/en- >> us/panel_classified.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/en- >> us/panel_group_general.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/en- >> us/panel_preferences_general.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/en- >> us/panel_preferences_voice.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/es/ >> floater_about.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/es/ >> floater_chat_history.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/es/ >> panel_preferences_audio.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/es/ >> panel_preferences_chat.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/es/ >> panel_preferences_general.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/ko/ >> floater_about.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/ko/ >> floater_chat_history.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/pl/ >> floater_about.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/pl/ >> floater_buy_land.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/pl/ >> floater_chat_history.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/pt/ >> floater_about.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/pt/ >> floater_chat_history.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/pt/ >> panel_preferences_audio.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/ru/ >> floater_about.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/ru/ >> floater_chat_history.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/uk/ >> floater_chat_history.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/zh/ >> floater_about.xml >> M /projects/2009/http-texture/indra/newview/skins/default/xui/zh/ >> floater_chat_history.xml >> M /projects/2009/http-texture/install.xml >> >> svn merge -r2162:2229 https://svn.secondlife.com/svn/linden/branches/2009/http-texture >> Update to newest (1.23 RC0 + http-texture) >> ------------------------------------------------------------------------ >> r2232 | merov.linden | 2009-05-07 18:52:21 -0700 (Thu, 07 May 2009) >> | 1 line >> Changed paths: >> M /projects/2009/http-texture/indra/newview/lltexturefetch.cpp >> >> VWR-12775 : race condition avoidance on decode callback (1 liner). >> Tested but not reviewed yet! >> ------------------------------------------------------------------------ >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits >> >> >> >> >> > > _______________________________________________ > 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 May 8 18:05:53 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 08 May 2009 18:05:53 -0700 Subject: [sldev] [Fwd: [sldev-commits] Successful Build for http-texture (2235)] Message-ID: <4A04D6F1.9080605@lindenlab.com> This one seems to fix VWR-12775 in my limited testing....please give this one a spin! -------- Original Message -------- Subject: [sldev-commits] Successful Build for http-texture (2235) Date: Fri, 8 May 2009 18:03:56 -0700 (PDT) From: buildadmin at lindenlab.com To: sldev-commits at lists.secondlife.com CYGWIN: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2235/Second_Life_1-23-0-2235_OSS_Setup.exe http://secondlife.com/developers/opensource/downloads/2009/http-texture/2235/good-build.CYGWIN Darwin: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2235/SecondLife_1_23_0_2235_OSS.dmg http://secondlife.com/developers/opensource/downloads/2009/http-texture/2235/good-build.Darwin Linux: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2235/SecondLife-i686-1.23.0.2235.tar.bz2 http://secondlife.com/developers/opensource/downloads/2009/http-texture/2235/good-build.Linux ------------------------------------------------------------------------ r2235 | merov.linden | 2009-05-08 14:28:17 -0700 (Fri, 08 May 2009) | 1 line Changed paths: M /projects/2009/http-texture/indra/newview/lltexturefetch.cpp VWR-12775: committed a simple patch that circunvents (but doesn't fix...) the most gregarious crashers ------------------------------------------------------------------------ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits From open at autistici.org Sat May 9 19:32:44 2009 From: open at autistici.org (Opensource Obscure) Date: Sun, 10 May 2009 02:32:44 +0000 Subject: [sldev] Output Debug Minidump Message-ID: <7feaa90320cc45e867fd195a4b1d40c6@localhost> What does Advanced > Output Debug Minidump do? By the way, it's enabled by default and I see some people suggest to disable it when dealing with viewer freezes: https://jira.secondlife.com/browse/VWR-11841 http://jira.secondlife.com/browse/VWR-7779 Some comments suggest it provides more informative logs so I'll keep it enabled by default, but I'm thinking - maybe it makes sense to disable this when you absolutely need to minimize freezes and glitches e.g. making a video? ciao Opensource Obscure From gbrandon at gmail.com Sat May 9 21:57:39 2009 From: gbrandon at gmail.com (Brandon Lockaby) Date: Sun, 10 May 2009 00:57:39 -0400 Subject: [sldev] Concept of "loaded avatar" was changed? Message-ID: Was browsing the SL JIRA and noticed a few people mentioning issues like this "Version 1.23.1 (May 4th) viewer will not rez bots" http://jira.secondlife.com/browse/VWR-13386 No surprise if there was no notice or documentation but does anyone know if it is true that the requirements of what makes an avatar appear "loaded" are being changed? Thanks, Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090510/9c5880f3/attachment.htm From dahliatrimble at gmail.com Sat May 9 22:06:03 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sat, 9 May 2009 22:06:03 -0700 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: References: Message-ID: Many bots don't use "baked", or composite textures, rather they rely on viewers to download all the clothing layers and display them. I've heard that new viewers would no longer download all texture layers for other avatars. Perhaps this feature has made it into the new RC viewer? On Sat, May 9, 2009 at 9:57 PM, Brandon Lockaby wrote: > Was browsing the SL JIRA and noticed a few people mentioning issues like > this "Version 1.23.1 (May 4th) viewer will not rez bots" > http://jira.secondlife.com/browse/VWR-13386 > > No surprise if there was no notice or documentation but does anyone know if > it is true that the requirements of what makes an avatar appear "loaded" are > being changed? > > Thanks, > Brandon > > _______________________________________________ > 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/20090509/2aaf55e2/attachment.htm From mrfrans at gmail.com Sat May 9 22:29:49 2009 From: mrfrans at gmail.com (Frans) Date: Sun, 10 May 2009 07:29:49 +0200 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: References: Message-ID: <7765f2c60905092229q30ce41edi63e653d8eaf1b351@mail.gmail.com> That would make sense in many ways. On Sun, May 10, 2009 at 7:06 AM, Dahlia Trimble wrote: > Many bots don't use "baked", or composite textures, rather they rely on > viewers to download all the clothing layers and display them. I've heard > that new viewers would no longer download all texture layers for other > avatars. Perhaps this feature has made it into the new RC viewer? > > -- Jeroen Frans Virtual World Technology Specialist. TheVesuviusGroup.com SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090510/73fda000/attachment.htm From kf6kjg at gmail.com Sat May 9 22:51:01 2009 From: kf6kjg at gmail.com (Ricky) Date: Sat, 9 May 2009 22:51:01 -0700 Subject: [sldev] ZLib and Boost In-Reply-To: <4A0493C5.8010308@lindenlab.com> References: <3bb9647e0905062311t1e47c399p16b072ee9dd3d092@mail.gmail.com> <4A0493C5.8010308@lindenlab.com> Message-ID: <3bb9647e0905092251v63eaec75ia5b7732e5c242ee9@mail.gmail.com> NP, thanks for the comprehensive response! Is there a PJIRA entry for this so that I can look up the reasons for the change? It might be good to get this in the http-texture project (and other branches/projects) soon, as it changes the build process slightly... At least enough to require an update to my scripts that is incompatible with http-texture: develop.py crashes if you pass it a parameter it doesn't recognize. :D Ricky On Fri, May 8, 2009 at 1:19 PM, Brad Kittenbrink (Brad Linden) < brad at lindenlab.com> wrote: > Oops, I think you got tripped up by a change we recently made to trunk for > building our 32 bit viewers on 64 bit machines. I meant to announce this > here ahead of time, but it slipped through the cracks. > > I think anyone doing standalone builds on 64 bit distributions will get the > same errors. > > There is now a new (as of r2201 i think) optional argument to develop.py > (and equivalently a new cmake variable) to configure whether you are > building 32bit or 64bit code, and it defaults to 32bit. > > If you want to build a 64bit viewer you probably want to configure using > something like the following: > ./develop.py -m64 --standalone configure > > If you want to build a 32bit viewer, you'll need your distro's 32bit > development libs installed (on debian it's called libc6-dev-i386 and I > additionally needed libglu1-mesa-dev) and you'll either need to do a > non-standalone build, or build 32bit versions of all third party libs. > > If you're not using develop.py and running cmake by hand you'll need to > pass -DWORD_SIZE=64 as an extra argument to cmake to override the default. > > apologies for the surprise, > -Brad > > Ricky wrote: > >> Have the version requirements for zlib and boost changed recently (as in >> within the last 3 months)? >> >> I get the following error on compile, and the last time I compiled, (April >> 16 according to my logs,) it ran just fine... >> >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: >> skipping incompatible /lib64/libz.so when searching for -lz >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: >> skipping incompatible /lib64/libz.so when searching for -lz >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: >> skipping incompatible >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../libboost_signals-mt.so when >> searching for -lboost_signals-mt >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: >> skipping incompatible /usr/lib/libboost_signals-mt.so when searching for >> -lboost_signals-mt >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: >> cannot find -lboost_signals-mt >> collect2: ld returned 1 exit status >> >> I'm compiling against trunk, revision 2227. (Latest edition as of this >> writing.) >> >> Thanks, >> 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/20090509/07e76f03/attachment.htm From kf6kjg at gmail.com Sat May 9 23:08:54 2009 From: kf6kjg at gmail.com (Ricky) Date: Sat, 9 May 2009 23:08:54 -0700 Subject: [sldev] Standalone build without root access (in partial ref to VWR-10579) Message-ID: <3bb9647e0905092308r3c7e5640m93510f25d37a8a1c@mail.gmail.com> Before I even start, I DO have root access on my machine, which is the one I am using to build. I try not to use root though, for well-discussed/obvious reasons. When I wrote my patch(es) for VWR-10579, I had a reference to a in-the-build-tree library location. This was incorrect, as is well discussed in the JIRA entry. The proper place is to put the compiled library in /usr/local/. But, having said that... What if I have some "custom" libraries (like we were dealing with in VWR-10579) and I either don't have root access, or I don't want to set up my script to have root access, to copy the custom library to /usr/local/? My situation is that I wrote a pair of scripts that manage (update.sh) updating, grabbing and/or compiling the dependencies, patching, and (build.sh) configuring/compiling the tree. The script "update.sh" actually goes and verifies that I have the latest NDOFDEV source, and compiles it. To get this to where it SHOULD be, I would have to either have my script elevate to root to copy the files over, or I would have to do so manually. Is there/can there be a "semi" proper location to put such that doesn't require root privs? I also understand that this would all be largely a moot point if I weren't compiling standalone... :P Ricky aka Cron Stardust -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090509/b1d6c768/attachment.htm From aimee.trescothick at gmail.com Sun May 10 05:04:52 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Sun, 10 May 2009 13:04:52 +0100 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: References: Message-ID: <1A26D3AE-3819-48D9-AB49-9CE18C26B6E5@gmail.com> For anyone interested in this subject, I'd suggest going to Nyx Linden's office hours on Wednesdays if you can, as he's working on it, along with BigPapi Linden who is often there too. http://wiki.secondlife.com/wiki/User:Nyx_Linden/Office_Hours Aimee. On 10 May 2009, at 06:06, Dahlia Trimble wrote: > Many bots don't use "baked", or composite textures, rather they rely > on viewers to download all the clothing layers and display them. > I've heard that new viewers would no longer download all texture > layers for other avatars. Perhaps this feature has made it into the > new RC viewer? From kf6kjg at gmail.com Sun May 10 11:56:11 2009 From: kf6kjg at gmail.com (Ricky) Date: Sun, 10 May 2009 11:56:11 -0700 Subject: [sldev] Issues with the text areas in Trunk Message-ID: <3bb9647e0905101156r3c96c6f1le0a4bd94a41b1f80@mail.gmail.com> I just created VWR-13406 (Not all line numbers in scripts show when using smaller UI scale) and VWR-13407 (Wrong cursor when over text areas) These two issues may or may not be related. VWR-13406 contains a screenshot of the issue. I do not yet have enough knowledge of the code to find the problem. I also haven't yet found which revision introduced the problem. Any repo's? I am compiling against latest trunk. (r2237) Ricky aka Cron Stardust From chaosstar at gmail.com Mon May 11 00:57:28 2009 From: chaosstar at gmail.com (Ambrosia) Date: Mon, 11 May 2009 09:57:28 +0200 Subject: [sldev] would this help with increasing the apparent number of light sources at all? In-Reply-To: <0016361645a5633eaa04695f54de@google.com> References: <4A03B2DE.8030602@Gmail.com> <0016361645a5633eaa04695f54de@google.com> Message-ID: <9bb32d430905110057v6ef18b43o16a7c3c430fc4bdd@mail.gmail.com> You can use it without shadows, that's the beauty. Once RenderUseFBO and RenderDeferred are enabled, simply deactiavate RenderSunShdaows(?). I think that was the debug param. And voila, you have the deferred renderer without any shadowing. I however don't know if shadow calculations aren't still going on in the background, and this simply turns off the rendering of those. On Fri, May 8, 2009 at 06:47, wrote: > Theres already a system for infinite light sources in the shadow-draft > client. Why not just use that minus shadows? I have been meaning to ask this > for a long time. > _______________________________________________ > 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 cenji.neutra at gmail.com Mon May 11 09:34:42 2009 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Mon, 11 May 2009 12:34:42 -0400 Subject: [sldev] SL OpenID authentication Message-ID: Hi all. Does anyone know if there is public information about OpenID authentication for SL avatars? It appears that logins to xstreetsl.com are handled by an LL OpenID provider located at id.secondlife.com. Is that planned to be available for public consumption? (does it work already?). What exactly is the OpenID for an avatar now? I couldn't find any information about this service on the wiki or anywhere. If I've missed it, apologies for the bandwidth; otherwise I'd appreciate if a Linden could chime in with something :) We (Apez Corp) have considered becoming an OpenID provider for SL avatars on and off for a while, but it would be much nicer if we could just be a consumer of LL's service. I've seen other SL avatar OpenID providers around in the past (don't recall who or where now). Thanks. From me at signpostmarv.name Mon May 11 10:00:58 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Mon, 11 May 2009 18:00:58 +0100 Subject: [sldev] SL OpenID authentication In-Reply-To: References: Message-ID: <4A0859CA.8080105@signpostmarv.name> I've been an OpenID provider for SL avatars, using 2 different techs. Regarding the ID url, it appears that they're using directed identity. ~ Marv. Cenji Neutra wrote: > Hi all. Does anyone know if there is public information about OpenID > authentication for SL avatars? > It appears that logins to xstreetsl.com are handled by an LL OpenID > provider located at id.secondlife.com. Is that planned to be > available for public consumption? (does it work already?). > What exactly is the OpenID for an avatar now? > > I couldn't find any information about this service on the wiki or > anywhere. If I've missed it, apologies for the bandwidth; otherwise > I'd appreciate if a Linden could chime in with something :) > > We (Apez Corp) have considered becoming an OpenID provider for SL > avatars on and off for a while, but it would be much nicer if we could > just be a consumer of LL's service. I've seen other SL avatar OpenID > providers around in the past (don't recall who or where now). > > Thanks. > _______________________________________________ > 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/20090511/d53c2434/attachment.bin From cenji.neutra at gmail.com Mon May 11 10:14:57 2009 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Mon, 11 May 2009 13:14:57 -0400 Subject: [sldev] SL OpenID authentication In-Reply-To: <72ab2b540905111001i73f14807k22c450ca874a2dfe@mail.gmail.com> References: <72ab2b540905111001i73f14807k22c450ca874a2dfe@mail.gmail.com> Message-ID: On Mon, May 11, 2009 at 1:01 PM, Alexander Fedotov

wrote: > It's not an "Open" ID, it's their proprietary ID system. Ah. I just assumed since the URL was id.secondlife.com/openid/login... perhaps it isn't OpenID at all then. I know a LL dev I spoke with once about a year ago (forget who) said (unofficially) they were considering it. From cenji.neutra at gmail.com Mon May 11 10:23:46 2009 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Mon, 11 May 2009 13:23:46 -0400 Subject: [sldev] SL OpenID authentication In-Reply-To: <4A0859CA.8080105@signpostmarv.name> References: <4A0859CA.8080105@signpostmarv.name> Message-ID: On Mon, May 11, 2009 at 1:00 PM, SignpostMarv Martin wrote: > I've been an OpenID provider for SL avatars, using 2 different techs. No doubt it was yours I stumbled across a while back :) > Regarding the ID url, it appears that they're using directed identity. So - it is OpenID then? OpenID 2.0? From me at signpostmarv.name Mon May 11 10:26:12 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Mon, 11 May 2009 18:26:12 +0100 Subject: [sldev] SL OpenID authentication In-Reply-To: References: <4A0859CA.8080105@signpostmarv.name> Message-ID: <4A085FB4.3020506@signpostmarv.name> Whatever it is, it fails in some browsers :-P http://jira.secondlife.com/browse/WEB-1093 ~ Marv. Cenji Neutra wrote: > On Mon, May 11, 2009 at 1:00 PM, SignpostMarv Martin > wrote: > >> I've been an OpenID provider for SL avatars, using 2 different techs. >> > > No doubt it was yours I stumbled across a while back :) > > >> Regarding the ID url, it appears that they're using directed identity. >> > > So - it is OpenID then? OpenID 2.0? > > -------------- 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/20090511/36cf01d5/attachment.bin From Nyx at lindenlab.com Mon May 11 10:30:58 2009 From: Nyx at lindenlab.com (Nyx Linden) Date: Mon, 11 May 2009 13:30:58 -0400 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: References: Message-ID: <4A0860D2.1070906@lindenlab.com> Yes, we are moving to a system where an avatar is "loaded" if it has baked textures. Local textures (individual layers) are still present for the time being for support for legacy viewers, but starting with 1.23, clients no longer "bake" textures for other avatars (only for yourself). An avatar is considered to be defined if it has the following textures set: TEX_HEAD_BAKED TEX_UPPER_BAKED TEX_LOWER_BAKED TEX_EYES_BAKED TEX_HAIR_BAKED* (*Note that hair was not actually baked pre-1.23. The existence of baked hair indicates a 1.23+ client. 1.23 will still "bake" hair for other avatars that do not provide baked hair, but this will not be true in future versions of the viewer) I'll be investigating possibilities for bot owners to consider, but feel free to stop by my office hours at noon on Wednesdays in Borrowdale (http://slurl.com/secondlife/Borrowdale/74/217/33) for the latest discussion of avatar issues and improvements (or post further here, I'm happy to answer any questions). -Nyx Dahlia Trimble wrote: > Many bots don't use "baked", or composite textures, rather they rely > on viewers to download all the clothing layers and display them. I've > heard that new viewers would no longer download all texture layers for > other avatars. Perhaps this feature has made it into the new RC viewer? > > On Sat, May 9, 2009 at 9:57 PM, Brandon Lockaby > wrote: > > Was browsing the SL JIRA and noticed a few people mentioning > issues like this "Version 1.23.1 (May 4th) viewer will not rez > bots" http://jira.secondlife.com/browse/VWR-13386 > > No surprise if there was no notice or documentation but does > anyone know if it is true that the requirements of what makes an > avatar appear "loaded" are being changed? > > Thanks, > Brandon > > _______________________________________________ > 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 GordonWendt at gmail.com Mon May 11 10:42:39 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon, 11 May 2009 10:42:39 -0700 Subject: [sldev] SL OpenID authentication In-Reply-To: <4A085FB4.3020506@signpostmarv.name> References: <4A0859CA.8080105@signpostmarv.name> <4A085FB4.3020506@signpostmarv.name> Message-ID: <493033a70905111042s787c7516ycc9f4ad82dc50b3c@mail.gmail.com> A bit OT but somewhat relevent to this new system... Whatever it is supposedly the plan is to eventually move all the logins over to this system and to go into a single sessions sytem, i.e. you log into the blog and on the same session you can go to the forums, the blogs, slx, etc... without having to log back in to each service seperately. I'd hope that this would come with a customizeable timeout though and/or the implementation of the seperate login name from your avatar name for security reasons if they're going to more deeply integrate this. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090511/0ea5e566/attachment-0001.htm From oken65 at gmail.com Mon May 11 10:42:16 2009 From: oken65 at gmail.com (Oken) Date: Mon, 11 May 2009 19:42:16 +0200 Subject: [sldev] SL OpenID authentication In-Reply-To: <4A085FB4.3020506@signpostmarv.name> References: <4A0859CA.8080105@signpostmarv.name> <4A085FB4.3020506@signpostmarv.name> Message-ID: <4A086378.3040305@gmail.com> Already 3 Jira about it: http://jira.secondlife.com/browse/WEB-1090 http://jira.secondlife.com/browse/WEB-1091 http://jira.secondlife.com/browse/WEB-1093 SignpostMarv Martin a ?crit : > Whatever it is, it fails in some browsers :-P > > http://jira.secondlife.com/browse/WEB-1093 > > > ~ Marv. > > Cenji Neutra wrote: >> On Mon, May 11, 2009 at 1:00 PM, SignpostMarv Martin >> wrote: >> >>> I've been an OpenID provider for SL avatars, using 2 different techs. >>> >> >> No doubt it was yours I stumbled across a while back :) >> >> >>> Regarding the ID url, it appears that they're using directed identity. >>> >> >> So - it is OpenID then? OpenID 2.0? >> >> > ------------------------------------------------------------------------ > > _______________________________________________ > 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 dzonux.net Sat May 9 10:08:39 2009 From: dzonatas at dzonux.net (Dzonatas) Date: Sat, 09 May 2009 10:08:39 -0700 Subject: [sldev] [Fwd: [sldev-commits] Successful Build for http-texture (2235)] In-Reply-To: <4A04D6F1.9080605@lindenlab.com> References: <4A04D6F1.9080605@lindenlab.com> Message-ID: <4A05B897.8040001@dzonux.net> Here is an example of a race condition that sticks out like a sore thumb. We'll take the example from the recent changeset: http://svn.secondlife.com/trac/linden/changeset/2232 In there it shows this code: mRawImage.notNull() && mRawImage->getDataSize() That kind of function call, to test for null first then call the function, is found in many places in the source. The comment provides a hint the race condition happens in such function call, but given that style of call still exists in the code, I don't think it is truly understood. One should not need a stack trace to realize that the function call above will cause crashes. Sure, there are ways to circumvent it by clever uses of flags. One thing I like about C# with delegates is that you get the speed of a function call without locks, like above, but also can eliminate the race condition with a simple step and not resort to locks. For example, in C#: delegate void DataSizeHandler() ; public static event DataSizeHandler DataSize; ... if( DataSize ) DataSize() That code above causes race conditions. If DataSize is not assigned to some valid function, which would make it null, it should not be called. First, let's assign it to a valid function: DataSize += RawImage.DataSize; So, now DataSize is set to non null, the if-condition lets the call happen. Along comes another thread that change the value of DataSize after the if-condition test true but before the call to DataSize(): DataSize -= RawImage.DataSize; We can see now how the attempt to make the function call to DataSize will still crash and how the if-condition was a false sense of security that it wouldn't crash -- maybe avoided when another thread would execute in between the if-condition and the call. We know threads execute anytime and the possibility will happen. We need to eliminate that possibility. In C#, there is an easy way to make it so this never ever crashes: delegate void DataSizeHandler() ; public static event DataSizeHandler DataSize = delegate { } ; ... DataSize() The difference here is the use of an anonymous delegate. Events in C# are multicast, so if DataSize is not assigned with RawImage.DataSize, then DataSize will still call the empty anonymous function. Anotherwords, it's never null. Since it is never null, there is never a crash for because of a null value. The other threads can add and remove function assignments anytime without locks and never cause a crash. Now I'm sure you may say, but that is C# and not C++. Yes, this example I made is in C#. What is needed in C++ is something *like* C# delegates (with anonymous delegates), which would solve these race conditions. Maybe google some examples, but the key thing that needs to happen is the lockless assign/deassign, and instead of a null value, it points to a valid function. It could be a dummy function. Being that the dummy function would require the same parameters, no doubt that every one of these functions calls like mRawImage->getDataSize() starts to look more like a need for a template class to wrap each declaration. Cheers Rob Lanphier wrote: > This one seems to fix VWR-12775 in my limited testing....please give > this one a spin! > -------- Original Message -------- > Subject: [sldev-commits] Successful Build for http-texture (2235) > Date: Fri, 8 May 2009 18:03:56 -0700 (PDT) > From: buildadmin at lindenlab.com > To: sldev-commits at lists.secondlife.com > > > > CYGWIN: > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2235/Second_Life_1-23-0-2235_OSS_Setup.exe > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2235/good-build.CYGWIN > > Darwin: > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2235/SecondLife_1_23_0_2235_OSS.dmg > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2235/good-build.Darwin > > Linux: > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2235/SecondLife-i686-1.23.0.2235.tar.bz2 > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2235/good-build.Linux > > ------------------------------------------------------------------------ > r2235 | merov.linden | 2009-05-08 14:28:17 -0700 (Fri, 08 May 2009) | 1 line > Changed paths: > M /projects/2009/http-texture/indra/newview/lltexturefetch.cpp > > VWR-12775: committed a simple patch that circunvents (but doesn't fix...) the most gregarious crashers > ------------------------------------------------------------------------ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits > > _______________________________________________ > 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 Mon May 11 11:22:03 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Mon, 11 May 2009 11:22:03 -0700 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <4A0860D2.1070906@lindenlab.com> References: <4A0860D2.1070906@lindenlab.com> Message-ID: How about the skirt texture? Also, is the baked hair texture necessary for display in 1.23? what about avatars wearing a "bald base" and prim hair? On Mon, May 11, 2009 at 10:30 AM, Nyx Linden wrote: > Yes, we are moving to a system where an avatar is "loaded" if it has baked > textures. Local textures (individual layers) are still present for the time > being for support for legacy viewers, but starting with 1.23, clients no > longer "bake" textures for other avatars (only for yourself). An avatar is > considered to be defined if it has the following textures set: > > TEX_HEAD_BAKED > TEX_UPPER_BAKED > TEX_LOWER_BAKED > TEX_EYES_BAKED > TEX_HAIR_BAKED* > > (*Note that hair was not actually baked pre-1.23. The existence of baked > hair indicates a 1.23+ client. 1.23 will still "bake" hair for other avatars > that do not provide baked hair, but this will not be true in future versions > of the viewer) > > I'll be investigating possibilities for bot owners to consider, but feel > free to stop by my office hours at noon on Wednesdays in Borrowdale ( > http://slurl.com/secondlife/Borrowdale/74/217/33) for the latest > discussion of avatar issues and improvements (or post further here, I'm > happy to answer any questions). > > -Nyx > > > > Dahlia Trimble wrote: > >> Many bots don't use "baked", or composite textures, rather they rely on >> viewers to download all the clothing layers and display them. I've heard >> that new viewers would no longer download all texture layers for other >> avatars. Perhaps this feature has made it into the new RC viewer? >> >> On Sat, May 9, 2009 at 9:57 PM, Brandon Lockaby > gbrandon at gmail.com>> wrote: >> >> Was browsing the SL JIRA and noticed a few people mentioning >> issues like this "Version 1.23.1 (May 4th) viewer will not rez >> bots" http://jira.secondlife.com/browse/VWR-13386 >> >> No surprise if there was no notice or documentation but does >> anyone know if it is true that the requirements of what makes an >> avatar appear "loaded" are being changed? >> >> Thanks, >> Brandon >> >> _______________________________________________ >> 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/20090511/6d8b4bb3/attachment.htm From cenji.neutra at gmail.com Mon May 11 11:26:02 2009 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Mon, 11 May 2009 14:26:02 -0400 Subject: [sldev] SL OpenID authentication Message-ID: Just a bit of info: according to the redirect URL, our OpenIDs are of the form: https://id.secondlife.com/id/. (e.g. https://id.secondlife.com/id/Cenji.Neutra is mine) I tried logging into several 3rd-party sites using this as an OpenID and it failed. It appears that most sites want http not https and LL's server doesn't respond to http. How about it LL? ;) From tom at streamsense.net Mon May 11 11:28:44 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Mon, 11 May 2009 19:28:44 +0100 Subject: [sldev] SL OpenID authentication In-Reply-To: References: Message-ID: <4A086E5C.8010007@streamsense.net> That's their flaw, not LL's flaw, https is the sensible protocol to use. ~T Cenji Neutra wrote: > Just a bit of info: according to the redirect URL, our OpenIDs are of the form: > https://id.secondlife.com/id/. > (e.g. https://id.secondlife.com/id/Cenji.Neutra is mine) > > I tried logging into several 3rd-party sites using this as an OpenID > and it failed. It appears that most sites want http not https and > LL's server doesn't respond to http. > > How about it LL? ;) > _______________________________________________ > 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 me at signpostmarv.name Mon May 11 11:32:56 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Mon, 11 May 2009 19:32:56 +0100 Subject: [sldev] SL OpenID authentication In-Reply-To: <4A086E5C.8010007@streamsense.net> References: <4A086E5C.8010007@streamsense.net> Message-ID: <4A086F58.3010408@signpostmarv.name> If an OpenID provider is setup correctly, it'll work with this: http://openidenabled.com/resources/openid-test/diagnose-server/ LL's OpenID stuffs don't. ~ Marv. Thomas Grimshaw wrote: > That's their flaw, not LL's flaw, https is the sensible protocol to use. > > ~T > > Cenji Neutra wrote: > >> Just a bit of info: according to the redirect URL, our OpenIDs are of the form: >> https://id.secondlife.com/id/. >> (e.g. https://id.secondlife.com/id/Cenji.Neutra is mine) >> >> I tried logging into several 3rd-party sites using this as an OpenID >> and it failed. It appears that most sites want http not https and >> LL's server doesn't respond to http. >> >> How about it LL? ;) >> _______________________________________________ >> 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 -------------- 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/20090511/4a48c81a/attachment-0001.bin From robla at lindenlab.com Mon May 11 11:48:13 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Mon, 11 May 2009 11:48:13 -0700 Subject: [sldev] SL OpenID authentication In-Reply-To: <4A086F58.3010408@signpostmarv.name> References: <4A086E5C.8010007@streamsense.net> <4A086F58.3010408@signpostmarv.name> Message-ID: <4A0872ED.4090001@lindenlab.com> Hi all, Our server isn't meant as a general purpose OpenID server. It's meant purely as a mechanism for integrating our websites. The best place to discuss this is here: https://www.xstreetsl.com/modules.php?name=Forums&file=viewforum&f=1 None of the people involved in this project follow sldev@ to the best of my knowledge, so this isn't a great place to discuss. If you'd like to discuss a general purpose OpenID server, the best thing to do is to file a feature request on jira.secondlife.com (and perhaps provide a pointer to that issue on this list). Let's not overwhelm this mailing list with that discussion. Thanks Rob On 05/11/2009 11:32 AM, SignpostMarv Martin wrote: > If an OpenID provider is setup correctly, it'll work with this: > http://openidenabled.com/resources/openid-test/diagnose-server/ > > LL's OpenID stuffs don't. > > > ~ Marv. > > Thomas Grimshaw wrote: >> That's their flaw, not LL's flaw, https is the sensible protocol to use. >> >> ~T >> >> Cenji Neutra wrote: >> >>> Just a bit of info: according to the redirect URL, our OpenIDs are >>> of the form: >>> https://id.secondlife.com/id/. >>> (e.g. https://id.secondlife.com/id/Cenji.Neutra is mine) >>> >>> I tried logging into several 3rd-party sites using this as an OpenID >>> and it failed. It appears that most sites want http not https and >>> LL's server doesn't respond to http. >>> >>> How about it LL? ;) >>> _______________________________________________ >>> 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 Nyx at lindenlab.com Mon May 11 12:11:50 2009 From: Nyx at lindenlab.com (Nyx Linden) Date: Mon, 11 May 2009 15:11:50 -0400 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: References: <4A0860D2.1070906@lindenlab.com> Message-ID: <4A087876.9080707@lindenlab.com> Skirt textres are baked and have been, but they are optional. If the TEX_SKIRT_BAKED is undefined, it means that the skirt should not be rendered, but it need not be defined for the rest of the avatar to be rendered. Avatars wearing a "bald base" still have a hair texture (and baked hair texture) defined. The baldness comes from shrinking the hair down into the head. The textures still have to be defined for the avatar to be rendered, however. -Nyx Dahlia Trimble wrote: > How about the skirt texture? Also, is the baked hair texture necessary > for display in 1.23? what about avatars wearing a "bald base" and prim > hair? > > On Mon, May 11, 2009 at 10:30 AM, Nyx Linden > wrote: > > Yes, we are moving to a system where an avatar is "loaded" if it > has baked textures. Local textures (individual layers) are still > present for the time being for support for legacy viewers, but > starting with 1.23, clients no longer "bake" textures for other > avatars (only for yourself). An avatar is considered to be defined > if it has the following textures set: > > TEX_HEAD_BAKED > TEX_UPPER_BAKED > TEX_LOWER_BAKED > TEX_EYES_BAKED > TEX_HAIR_BAKED* > > (*Note that hair was not actually baked pre-1.23. The existence of > baked hair indicates a 1.23+ client. 1.23 will still "bake" hair > for other avatars that do not provide baked hair, but this will > not be true in future versions of the viewer) > > I'll be investigating possibilities for bot owners to consider, > but feel free to stop by my office hours at noon on Wednesdays in > Borrowdale (http://slurl.com/secondlife/Borrowdale/74/217/33) for > the latest discussion of avatar issues and improvements (or post > further here, I'm happy to answer any questions). > > -Nyx > > > > Dahlia Trimble wrote: > > Many bots don't use "baked", or composite textures, rather > they rely on viewers to download all the clothing layers and > display them. I've heard that new viewers would no longer > download all texture layers for other avatars. Perhaps this > feature has made it into the new RC viewer? > > On Sat, May 9, 2009 at 9:57 PM, Brandon Lockaby > > >> wrote: > > Was browsing the SL JIRA and noticed a few people mentioning > issues like this "Version 1.23.1 (May 4th) viewer will not rez > bots" http://jira.secondlife.com/browse/VWR-13386 > > No surprise if there was no notice or documentation but does > anyone know if it is true that the requirements of what > makes an > avatar appear "loaded" are being changed? > > Thanks, > Brandon > > _______________________________________________ > 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 me at signpostmarv.name Mon May 11 12:25:58 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Mon, 11 May 2009 20:25:58 +0100 Subject: [sldev] SL OpenID authentication In-Reply-To: <4A0872ED.4090001@lindenlab.com> References: <4A086E5C.8010007@streamsense.net> <4A086F58.3010408@signpostmarv.name> <4A0872ED.4090001@lindenlab.com> Message-ID: <4A087BC6.8010004@signpostmarv.name> There's been one for ages: https://jira.secondlife.com/browse/WEB-60 ~ Marv. Rob Lanphier wrote: > Hi all, > > Our server isn't meant as a general purpose OpenID server. It's meant > purely as a mechanism for integrating our websites. > > The best place to discuss this is here: > https://www.xstreetsl.com/modules.php?name=Forums&file=viewforum&f=1 > > None of the people involved in this project follow sldev@ to the best of > my knowledge, so this isn't a great place to discuss. > > If you'd like to discuss a general purpose OpenID server, the best thing > to do is to file a feature request on jira.secondlife.com (and perhaps > provide a pointer to that issue on this list). Let's not overwhelm this > mailing list with that discussion. > > Thanks > Rob > > On 05/11/2009 11:32 AM, SignpostMarv Martin wrote: > >> If an OpenID provider is setup correctly, it'll work with this: >> http://openidenabled.com/resources/openid-test/diagnose-server/ >> >> LL's OpenID stuffs don't. >> >> >> ~ Marv. >> >> Thomas Grimshaw wrote: >> >>> That's their flaw, not LL's flaw, https is the sensible protocol to use. >>> >>> ~T >>> >>> Cenji Neutra wrote: >>> >>> >>>> Just a bit of info: according to the redirect URL, our OpenIDs are >>>> of the form: >>>> https://id.secondlife.com/id/. >>>> (e.g. https://id.secondlife.com/id/Cenji.Neutra is mine) >>>> >>>> I tried logging into several 3rd-party sites using this as an OpenID >>>> and it failed. It appears that most sites want http not https and >>>> LL's server doesn't respond to http. >>>> >>>> How about it LL? ;) >>>> _______________________________________________ >>>> 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 >> > > > -------------- 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/20090511/1e06b61b/attachment.bin From gbrandon at gmail.com Mon May 11 14:10:37 2009 From: gbrandon at gmail.com (Brandon Lockaby) Date: Mon, 11 May 2009 17:10:37 -0400 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <4A087876.9080707@lindenlab.com> References: <4A0860D2.1070906@lindenlab.com> <4A087876.9080707@lindenlab.com> Message-ID: Will the process of setting appearance, baking, uploading, then setting appearance again, still be the norm? Expecting an avatar to appear as a cloud until all of that uploading is done, seems like it could look bad if it takes a while. On Mon, May 11, 2009 at 3:11 PM, Nyx Linden wrote: > Skirt textres are baked and have been, but they are optional. If the > TEX_SKIRT_BAKED is undefined, it means that the skirt should not be > rendered, but it need not be defined for the rest of the avatar to be > rendered. > > Avatars wearing a "bald base" still have a hair texture (and baked hair > texture) defined. The baldness comes from shrinking the hair down into > the head. The textures still have to be defined for the avatar to be > rendered, however. > > -Nyx > > Dahlia Trimble wrote: > > How about the skirt texture? Also, is the baked hair texture necessary > > for display in 1.23? what about avatars wearing a "bald base" and prim > > hair? > > > > On Mon, May 11, 2009 at 10:30 AM, Nyx Linden > > wrote: > > > > Yes, we are moving to a system where an avatar is "loaded" if it > > has baked textures. Local textures (individual layers) are still > > present for the time being for support for legacy viewers, but > > starting with 1.23, clients no longer "bake" textures for other > > avatars (only for yourself). An avatar is considered to be defined > > if it has the following textures set: > > > > TEX_HEAD_BAKED > > TEX_UPPER_BAKED > > TEX_LOWER_BAKED > > TEX_EYES_BAKED > > TEX_HAIR_BAKED* > > > > (*Note that hair was not actually baked pre-1.23. The existence of > > baked hair indicates a 1.23+ client. 1.23 will still "bake" hair > > for other avatars that do not provide baked hair, but this will > > not be true in future versions of the viewer) > > > > I'll be investigating possibilities for bot owners to consider, > > but feel free to stop by my office hours at noon on Wednesdays in > > Borrowdale (http://slurl.com/secondlife/Borrowdale/74/217/33) for > > the latest discussion of avatar issues and improvements (or post > > further here, I'm happy to answer any questions). > > > > -Nyx > > > > > > > > Dahlia Trimble wrote: > > > > Many bots don't use "baked", or composite textures, rather > > they rely on viewers to download all the clothing layers and > > display them. I've heard that new viewers would no longer > > download all texture layers for other avatars. Perhaps this > > feature has made it into the new RC viewer? > > > > On Sat, May 9, 2009 at 9:57 PM, Brandon Lockaby > > > > >> wrote: > > > > Was browsing the SL JIRA and noticed a few people mentioning > > issues like this "Version 1.23.1 (May 4th) viewer will not rez > > bots" http://jira.secondlife.com/browse/VWR-13386 > > > > No surprise if there was no notice or documentation but does > > anyone know if it is true that the requirements of what > > makes an > > avatar appear "loaded" are being changed? > > > > Thanks, > > Brandon > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090511/86d6abec/attachment.htm From baloo at ursamundi.org Mon May 11 12:22:33 2009 From: baloo at ursamundi.org (Paul Johnson) Date: Mon, 11 May 2009 12:22:33 -0700 Subject: [sldev] SL OpenID authentication In-Reply-To: <4A0872ED.4090001@lindenlab.com> References: <4A086E5C.8010007@streamsense.net> <4A086F58.3010408@signpostmarv.name> <4A0872ED.4090001@lindenlab.com> Message-ID: Rob Lanphier wrote: > None of the people involved in this project follow sldev@ to the best of > my knowledge, so this isn't a great place to discuss. Seems silly that they aren't, given that it's pretty low traffic and accessible via gmane... > If you'd like to discuss a general purpose OpenID server, the best thing > to do is to file a feature request on jira.secondlife.com (and perhaps > provide a pointer to that issue on this list). Let's not overwhelm this > mailing list with that discussion. Once someone does this, could they be sure to post the JIRA link here, please? -------------- 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/20090511/5126a2fa/attachment-0001.pgp From secret.argent at gmail.com Mon May 11 18:10:06 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon, 11 May 2009 20:10:06 -0500 Subject: [sldev] SL OpenID authentication In-Reply-To: <493033a70905111042s787c7516ycc9f4ad82dc50b3c@mail.gmail.com> References: <4A0859CA.8080105@signpostmarv.name> <4A085FB4.3020506@signpostmarv.name> <493033a70905111042s787c7516ycc9f4ad82dc50b3c@mail.gmail.com> Message-ID: <661EAEB3-95B4-462F-B17F-CFE9C07BB29D@gmail.com> On 2009-05-11, at 12:42, Gordon Wendt wrote: > Whatever it is supposedly the plan is to eventually move all the > logins over to this system and to go into a single sessions sytem, > i.e. you log into the blog and on the same session you can go to the > forums, the blogs, slx, etc... without having to log back in to each > service seperately. I'd hope that this would come with a > customizeable timeout though and/or the implementation of the > seperate login name from your avatar name for security reasons if > they're going to more deeply integrate this. I'll take "the implementation of the seperate login name from your avatar name for security reasons" please please please please please. :) From secret.argent at gmail.com Mon May 11 18:14:24 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon, 11 May 2009 20:14:24 -0500 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <4A087876.9080707@lindenlab.com> References: <4A0860D2.1070906@lindenlab.com> <4A087876.9080707@lindenlab.com> Message-ID: <3257881B-2598-42DA-BE39-49559EAC3F23@gmail.com> Fascinating, Dr Nyx. On 2009-05-11, at 14:11, Nyx Linden wrote: > Skirt textres are baked and have been, but they are optional. If the > TEX_SKIRT_BAKED is undefined, it means that the skirt should not be > rendered, but it need not be defined for the rest of the avatar to be > rendered. Oh, so that's why we see a "missing skirt" problem sometimes? Is the hair base the reason why some avatars with a bald base have a completely insane square hairstyle for a few minutes after you log in? From carlo at alinoe.com Tue May 12 04:17:26 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 12 May 2009 13:17:26 +0200 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <4A0860D2.1070906@lindenlab.com> References: <4A0860D2.1070906@lindenlab.com> Message-ID: <20090512111726.GA7692@alinoe.com> Is this change going to fix the fact that when I'm TP-ing around with a friend, every time we TP both to a new location we have to wait (again) before we even see eachother, and after that have to wait a while until the skins are non-gray again? I mentioned this before; one would expect that if you TP somewhere else, that other avatars that you only saw seconds ago are instantly visible. On Mon, May 11, 2009 at 01:30:58PM -0400, Nyx Linden wrote: > Yes, we are moving to a system where an avatar is "loaded" if it has > baked textures. Local textures (individual layers) are still present for > the time being for support for legacy viewers, but starting with 1.23, > clients no longer "bake" textures for other avatars (only for yourself). > An avatar is considered to be defined if it has the following textures set: > > TEX_HEAD_BAKED > TEX_UPPER_BAKED > TEX_LOWER_BAKED > TEX_EYES_BAKED > TEX_HAIR_BAKED* > > (*Note that hair was not actually baked pre-1.23. The existence of baked > hair indicates a 1.23+ client. 1.23 will still "bake" hair for other > avatars that do not provide baked hair, but this will not be true in > future versions of the viewer) > > I'll be investigating possibilities for bot owners to consider, but feel > free to stop by my office hours at noon on Wednesdays in Borrowdale > (http://slurl.com/secondlife/Borrowdale/74/217/33) for the latest > discussion of avatar issues and improvements (or post further here, I'm > happy to answer any questions). > > -Nyx -- Carlo Wood From tateru.nino at gmail.com Tue May 12 05:38:31 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue, 12 May 2009 22:38:31 +1000 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <20090512111726.GA7692@alinoe.com> References: <4A0860D2.1070906@lindenlab.com> <20090512111726.GA7692@alinoe.com> Message-ID: <4A096DC7.10007@weblogsinc.com> You'd think so, wouldn't you? You should both have each-other's textures already cached at the very least. Unless the texture IDs change in a sim-crossing.... and they shouldn't do that, right? If those IDs aren't changing, then it looks like there's a false discard going on. Carlo Wood wrote: > Is this change going to fix the fact that when I'm TP-ing > around with a friend, every time we TP both to a new location > we have to wait (again) before we even see eachother, > and after that have to wait a while until the skins are > non-gray again? > > I mentioned this before; one would expect that if you TP > somewhere else, that other avatars that you only saw > seconds ago are instantly visible. > > On Mon, May 11, 2009 at 01:30:58PM -0400, Nyx Linden wrote: > >> Yes, we are moving to a system where an avatar is "loaded" if it has >> baked textures. Local textures (individual layers) are still present for >> the time being for support for legacy viewers, but starting with 1.23, >> clients no longer "bake" textures for other avatars (only for yourself). >> An avatar is considered to be defined if it has the following textures set: >> >> TEX_HEAD_BAKED >> TEX_UPPER_BAKED >> TEX_LOWER_BAKED >> TEX_EYES_BAKED >> TEX_HAIR_BAKED* >> >> (*Note that hair was not actually baked pre-1.23. The existence of baked >> hair indicates a 1.23+ client. 1.23 will still "bake" hair for other >> avatars that do not provide baked hair, but this will not be true in >> future versions of the viewer) >> >> I'll be investigating possibilities for bot owners to consider, but feel >> free to stop by my office hours at noon on Wednesdays in Borrowdale >> (http://slurl.com/secondlife/Borrowdale/74/217/33) for the latest >> discussion of avatar issues and improvements (or post further here, I'm >> happy to answer any questions). >> >> -Nyx >> > > -- Tateru Nino http://www.massively.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090512/b553eb80/attachment.htm From secret.argent at gmail.com Tue May 12 06:05:59 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 12 May 2009 08:05:59 -0500 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <20090512111726.GA7692@alinoe.com> References: <4A0860D2.1070906@lindenlab.com> <20090512111726.GA7692@alinoe.com> Message-ID: <6110C07B-06C9-4462-954A-2E664FFE9551@gmail.com> On 2009-05-12, at 06:17, Carlo Wood wrote: > Is this change going to fix the fact that when I'm TP-ing > around with a friend, every time we TP both to a new location > we have to wait (again) before we even see eachother, > and after that have to wait a while until the skins are > non-gray again? That sounds like a genuine bug, and you should write it up in Jira. This is apparently about making it a little harder for people who rip clothing layers from OpenGL, forcing them to actually buy the clothes they're going to rip. From aimee.trescothick at gmail.com Tue May 12 06:28:34 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Tue, 12 May 2009 14:28:34 +0100 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <4A096DC7.10007@weblogsinc.com> References: <4A0860D2.1070906@lindenlab.com> <20090512111726.GA7692@alinoe.com> <4A096DC7.10007@weblogsinc.com> Message-ID: <688F24A7-6C3D-4255-A07B-8DDE446E8841@gmail.com> On 12 May 2009, at 13:38, Tateru Nino wrote: > You'd think so, wouldn't you? You should both have each-other's > textures already cached at the very least. Unless the texture IDs > change in a sim-crossing.... and they shouldn't do that, right? If > those IDs aren't changing, then it looks like there's a false > discard going on. As far as I know, baked textures are only held as temporary textures on the sim, so they won't be available in the new region after a teleport until the client uploads them on arrival. However, if your client has baked textures cached for another avatar from the previous region ideally it should continue using those until it is able to obtain fresh ones from the new region, rather than clouding the avatar. That would give a more seamless experience than what appears to happen now. The only minor "issue" I can see with that at first inspection, is if the other person changes clothes before following you, in which case their appearance to you would be out of date until their new baked textures are available. Aimee. From open at autistici.org Tue May 12 06:52:46 2009 From: open at autistici.org (Opensource Obscure) Date: Tue, 12 May 2009 13:52:46 +0000 Subject: [sldev] [VWR, PATCH] VWR-2085: Hiding UI on Linux & http-texture branch Message-ID: <926a4b8e91f345320fc865d53ecb3781@localhost> This bug is old, has got patches and 23 votes and Linux users would like to see it fixed: Ctrl-Alt-F1 Hide/Show UI Does Not Work Correctly Under Linux http://jira.secondlife.com/browse/VWR-2085 Maybe this is a good idea for the http-texture viewer? I think it's an easy fix. Maybe changing all the shortcuts in the viewer would make more sense, and I know this was almost done; but there were no updates about this since a few months, and IMHO other shortcuts can wait. This feature is broken on Linux since 2 years and this is bad for both machinima and immersive SL experience in general. ciao Opensource Obscure From robin.cornelius at gmail.com Tue May 12 07:50:26 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue, 12 May 2009 15:50:26 +0100 Subject: [sldev] [PATCH] Allow XUI to specificy tooltips for combo box list entries Message-ID: Long over dew but patch at :- http://jira.secondlife.com/browse/VWR-13177 This patch complements Aimee's VWR-8008 which had feedback from the UI team to add tooltips to the combo box items (something that did not actually work then) is a patch that implements the feature of allowing the xui to specify tool tips for the predefined entries in a combos list display. The current tool tip display for a combo box is to display the same value as in the list (for the list items NOT the combo box as a whole). Which is not particularly helpful. It allows an XUI element to have a tool_tip attribute and then display this tool_tip for this specific item. It only shows this tool tip if it is defined else it falls back to the existing/default behavior for listboxes on combos. Can some one give it a check before i commit to http-texture, thanks Robin From robla at lindenlab.com Tue May 12 09:45:59 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 12 May 2009 09:45:59 -0700 Subject: [sldev] No really, try this one (SLDev viewer build 2244) Message-ID: <4A09A7C7.3090105@lindenlab.com> Yesterday, Merov and I discovered that 2235 really didn't fix VWR-12775. So, we bring you SLDev Viewer build 2244: Linux: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2244/SecondLife-i686-1.23.0.2244.tar.bz2 Mac: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2244/SecondLife_1_23_0_2244_OSS.dmg Windows: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2244/Second_Life_1-23-0-2244_OSS_Setup.exe Please give this one a whirl. I've been using it this morning without incident, and I'm hanging out on Hippotropolis now sorta testing it (ok...largely running in the background, but that's a test of sorts). Rob -------- Original Message -------- Subject: [sldev-commits] Successful Build for http-texture (2244) Date: Mon, 11 May 2009 17:49:28 -0700 (PDT) From: buildadmin at lindenlab.com To: sldev-commits at lists.secondlife.com Linux: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2244/SecondLife-i686-1.23.0.2244.tar.bz2 http://secondlife.com/developers/opensource/downloads/2009/http-texture/2244/good-build.Linux Darwin: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2244/SecondLife_1_23_0_2244_OSS.dmg http://secondlife.com/developers/opensource/downloads/2009/http-texture/2244/good-build.Darwin CYGWIN: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2244/Second_Life_1-23-0-2244_OSS_Setup.exe http://secondlife.com/developers/opensource/downloads/2009/http-texture/2244/good-build.CYGWIN ------------------------------------------------------------------------ r2235 | merov.linden | 2009-05-08 14:28:17 -0700 (Fri, 08 May 2009) | 1 line Changed paths: M /projects/2009/http-texture/indra/newview/lltexturefetch.cpp VWR-12775: committed a simple patch that circunvents (but doesn't fix...) the most gregarious crashers ------------------------------------------------------------------------ r2244 | merov.linden | 2009-05-11 16:43:49 -0700 (Mon, 11 May 2009) | 1 line Changed paths: M /projects/2009/http-texture/indra/newview/lltexturefetch.cpp VWR-12775: fixed further to avoid crash when mFormattedImage points to null ------------------------------------------------------------------------ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits From tigrospottystripes at gmail.com Tue May 12 12:22:32 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 12 May 2009 16:22:32 -0300 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <688F24A7-6C3D-4255-A07B-8DDE446E8841@gmail.com> References: <4A0860D2.1070906@lindenlab.com> <20090512111726.GA7692@alinoe.com> <4A096DC7.10007@weblogsinc.com> <688F24A7-6C3D-4255-A07B-8DDE446E8841@gmail.com> Message-ID: <4A09CC78.8060600@Gmail.com> Aimee Trescothick escreveu: > On 12 May 2009, at 13:38, Tateru Nino wrote: > >> You'd think so, wouldn't you? You should both have each-other's >> textures already cached at the very least. Unless the texture IDs >> change in a sim-crossing.... and they shouldn't do that, right? If >> those IDs aren't changing, then it looks like there's a false >> discard going on. >> > > > As far as I know, baked textures are only held as temporary textures > on the sim, so they won't be available in the new region after a > teleport until the client uploads them on arrival. > > However, if your client has baked textures cached for another avatar > from the previous region ideally it should continue using those until > it is able to obtain fresh ones from the new region, rather than > clouding the avatar. That would give a more seamless experience than > what appears to happen now. > > The only minor "issue" I can see with that at first inspection, is if > the other person changes clothes before following you, in which case > their appearance to you would be out of date until their new baked > textures are available. > > Aimee. > > > Shouldn't the servers share this info between them? From melinda at superliminal.com Tue May 12 13:07:09 2009 From: melinda at superliminal.com (Melinda Green) Date: Tue, 12 May 2009 13:07:09 -0700 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <4A09CC78.8060600@Gmail.com> References: <4A0860D2.1070906@lindenlab.com> <20090512111726.GA7692@alinoe.com> <4A096DC7.10007@weblogsinc.com> <688F24A7-6C3D-4255-A07B-8DDE446E8841@gmail.com> <4A09CC78.8060600@Gmail.com> Message-ID: <4A09D6ED.7020108@superliminal.com> Tigro Spottystripes wrote: > Aimee Trescothick escreveu: > >> On 12 May 2009, at 13:38, Tateru Nino wrote: >> >> >>> You'd think so, wouldn't you? You should both have each-other's >>> textures already cached at the very least. Unless the texture IDs >>> change in a sim-crossing.... and they shouldn't do that, right? If >>> those IDs aren't changing, then it looks like there's a false >>> discard going on. >>> >>> >> As far as I know, baked textures are only held as temporary textures >> on the sim, so they won't be available in the new region after a >> teleport until the client uploads them on arrival. >> >> However, if your client has baked textures cached for another avatar >> from the previous region ideally it should continue using those until >> it is able to obtain fresh ones from the new region, rather than >> clouding the avatar. That would give a more seamless experience than >> what appears to happen now. >> >> The only minor "issue" I can see with that at first inspection, is if >> the other person changes clothes before following you, in which case >> their appearance to you would be out of date until their new baked >> textures are available. >> >> Aimee. >> >> >> >> > > Shouldn't the servers share this info between them? I think it would be overkill to make sims share baked textures peer-to-peer, however there seems to me to be a simpler way to share baked textures which is to turn them into ordinary assets. Each avatar would only have a small, finite number of these so I wouldn't expect them put too much of a burden on the servers. I could even imagine good reasons to make baked textures part of the agent data, but in the short-run I wonder whether the simple solution would be to make baked textures into ordinary assets. -Melinda From tateru.nino at gmail.com Tue May 12 13:08:53 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed, 13 May 2009 06:08:53 +1000 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <4A09CC78.8060600@Gmail.com> References: <4A0860D2.1070906@lindenlab.com> <20090512111726.GA7692@alinoe.com> <4A096DC7.10007@weblogsinc.com> <688F24A7-6C3D-4255-A07B-8DDE446E8841@gmail.com> <4A09CC78.8060600@Gmail.com> Message-ID: <4A09D755.5050605@gmail.com> Tigro Spottystripes wrote: > Aimee Trescothick escreveu: > >> On 12 May 2009, at 13:38, Tateru Nino wrote: >> >> >>> You'd think so, wouldn't you? You should both have each-other's >>> textures already cached at the very least. Unless the texture IDs >>> change in a sim-crossing.... and they shouldn't do that, right? If >>> those IDs aren't changing, then it looks like there's a false >>> discard going on. >>> >>> >> As far as I know, baked textures are only held as temporary textures >> on the sim, so they won't be available in the new region after a >> teleport until the client uploads them on arrival. >> >> However, if your client has baked textures cached for another avatar >> from the previous region ideally it should continue using those until >> it is able to obtain fresh ones from the new region, rather than >> clouding the avatar. That would give a more seamless experience than >> what appears to happen now. >> >> The only minor "issue" I can see with that at first inspection, is if >> the other person changes clothes before following you, in which case >> their appearance to you would be out of date until their new baked >> textures are available. >> >> Aimee. >> >> >> >> > > Shouldn't the servers share this info between them? > > I don't recall ever seeing this problem with a companion walking or flying across a sim border. -- Tateru Nino http://www.massively.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090513/ef1bb3ec/attachment-0001.htm From kelly at lindenlab.com Tue May 12 13:25:23 2009 From: kelly at lindenlab.com (Kelly) Date: Tue, 12 May 2009 13:25:23 -0700 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <4A09D6ED.7020108@superliminal.com> References: <4A0860D2.1070906@lindenlab.com> <20090512111726.GA7692@alinoe.com> <4A096DC7.10007@weblogsinc.com> <688F24A7-6C3D-4255-A07B-8DDE446E8841@gmail.com> <4A09CC78.8060600@Gmail.com> <4A09D6ED.7020108@superliminal.com> Message-ID: <4A09DB33.7070005@lindenlab.com> Melinda Green wrote: > Tigro Spottystripes wrote: > >> Aimee Trescothick escreveu: >> >> >>> On 12 May 2009, at 13:38, Tateru Nino wrote: >>> >>> >>> >>>> You'd think so, wouldn't you? You should both have each-other's >>>> textures already cached at the very least. Unless the texture IDs >>>> change in a sim-crossing.... and they shouldn't do that, right? If >>>> those IDs aren't changing, then it looks like there's a false >>>> discard going on. >>>> >>>> >>>> >>> As far as I know, baked textures are only held as temporary textures >>> on the sim, so they won't be available in the new region after a >>> teleport until the client uploads them on arrival. >>> >>> However, if your client has baked textures cached for another avatar >>> from the previous region ideally it should continue using those until >>> it is able to obtain fresh ones from the new region, rather than >>> clouding the avatar. That would give a more seamless experience than >>> what appears to happen now. >>> >>> The only minor "issue" I can see with that at first inspection, is if >>> the other person changes clothes before following you, in which case >>> their appearance to you would be out of date until their new baked >>> textures are available. >>> >>> Aimee. >>> >>> >>> >>> >>> >> Shouldn't the servers share this info between them? >> > > I think it would be overkill to make sims share baked textures > peer-to-peer, however there seems to me to be a simpler way to share > baked textures which is to turn them into ordinary assets. Each avatar > would only have a small, finite number of these so I wouldn't expect > them put too much of a burden on the servers. I could even imagine good > reasons to make baked textures part of the agent data, but in the > short-run I wonder whether the simple solution would be to make baked > textures into ordinary assets. > > -Melinda Hey all! There are some misconceptions here about how this works on the back end, maybe I can clear it up. The following is the theory, apologies is reality doesn't quite match up. * When an avatar changes their outfit they bake their textures (akin to flattening layers in photoshop). * They then upload those textures to the simulator which stores the textures on an internally accessible web-dav server on the simulator host. * The simulator also stores information about where your baked textures are, in memory. In theory this should be a full URL but I think it is a host and a UUID instead. * The information about what host has your baked textures travels with you when you teleport or cross a region border, but the textures do not. * The textures should not need to get rebaked when you TP or region cross. Texture access (pre http-textures I think) is a funny thing. The client always gets textures from the simulator which usually gets them from the asset server and keeps them in a local cache. If it is a baked texture though the simulator fetches from the other simulator instead of the asset server, where "other server" is based on info in memory tied to the agent. If for any reason the simulator can't get the baked texture then it tells the agent's client to rebake. I believe most issues center around race conditions and the "couldn't find it, force a rebake and reupload" behavior. Baked textures used to be regular assets. Honestly we had a lot fewer issues with them then. However storing programatically generated textures in our central asset system caused too many assets to be created. The 'temporary asset' system was created specifically for this reason and specifically for baked textures. It is not something we are able to revert. That said I think the http-textures project may open up some great opportunities to improve this system. If we can refer to textures by url we can remove a lot of the more fragile pieces of this code path, and make 'temporary' textures more normal and more robust. - Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090512/2c23348c/attachment-0001.htm From melinda at superliminal.com Tue May 12 14:12:18 2009 From: melinda at superliminal.com (Melinda Green) Date: Tue, 12 May 2009 14:12:18 -0700 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <4A09DB33.7070005@lindenlab.com> References: <4A0860D2.1070906@lindenlab.com> <20090512111726.GA7692@alinoe.com> <4A096DC7.10007@weblogsinc.com> <688F24A7-6C3D-4255-A07B-8DDE446E8841@gmail.com> <4A09CC78.8060600@Gmail.com> <4A09D6ED.7020108@superliminal.com> <4A09DB33.7070005@lindenlab.com> Message-ID: <4A09E632.7060007@superliminal.com> Kelly wrote: > Melinda Green wrote: >> Tigro Spottystripes wrote: >> >>> Aimee Trescothick escreveu: >>> >>> >>>> On 12 May 2009, at 13:38, Tateru Nino wrote: >>>> >>>> >>>> >>>>> You'd think so, wouldn't you? You should both have each-other's >>>>> textures already cached at the very least. Unless the texture IDs >>>>> change in a sim-crossing.... and they shouldn't do that, right? If >>>>> those IDs aren't changing, then it looks like there's a false >>>>> discard going on. >>>>> >>>>> >>>>> >>>> As far as I know, baked textures are only held as temporary textures >>>> on the sim, so they won't be available in the new region after a >>>> teleport until the client uploads them on arrival. >>>> >>>> However, if your client has baked textures cached for another avatar >>>> from the previous region ideally it should continue using those until >>>> it is able to obtain fresh ones from the new region, rather than >>>> clouding the avatar. That would give a more seamless experience than >>>> what appears to happen now. >>>> >>>> The only minor "issue" I can see with that at first inspection, is if >>>> the other person changes clothes before following you, in which case >>>> their appearance to you would be out of date until their new baked >>>> textures are available. >>>> >>>> Aimee. >>>> >>>> >>>> >>>> >>>> >>> Shouldn't the servers share this info between them? >>> >> >> I think it would be overkill to make sims share baked textures >> peer-to-peer, however there seems to me to be a simpler way to share >> baked textures which is to turn them into ordinary assets. Each avatar >> would only have a small, finite number of these so I wouldn't expect >> them put too much of a burden on the servers. I could even imagine good >> reasons to make baked textures part of the agent data, but in the >> short-run I wonder whether the simple solution would be to make baked >> textures into ordinary assets. >> >> -Melinda > Hey all! There are some misconceptions here about how this works on > the back end, maybe I can clear it up. The following is the theory, > apologies is reality doesn't quite match up. > > * When an avatar changes their outfit they bake their textures (akin > to flattening layers in photoshop). > * They then upload those textures to the simulator which stores the > textures on an internally accessible web-dav server on the simulator host. > * The simulator also stores information about where your baked > textures are, in memory. In theory this should be a full URL but I > think it is a host and a UUID instead. > * The information about what host has your baked textures travels with > you when you teleport or cross a region border, but the textures do not. > * The textures should not need to get rebaked when you TP or region cross. > > Texture access (pre http-textures I think) is a funny thing. The > client always gets textures from the simulator which usually gets them > from the asset server and keeps them in a local cache. If it is a > baked texture though the simulator fetches from the other simulator > instead of the asset server, where "other server" is based on info in > memory tied to the agent. If for any reason the simulator can't get > the baked texture then it tells the agent's client to rebake. > > I believe most issues center around race conditions and the "couldn't > find it, force a rebake and reupload" behavior. > > Baked textures used to be regular assets. Honestly we had a lot fewer > issues with them then. However storing programatically generated > textures in our central asset system caused too many assets to be > created. The 'temporary asset' system was created specifically for > this reason and specifically for baked textures. It is not something > we are able to revert. That said I think the http-textures project > may open up some great opportunities to improve this system. If we > can refer to textures by url we can remove a lot of the more fragile > pieces of this code path, and make 'temporary' textures more normal > and more robust. Kelly, Thank you for the additional background and technical details. It does sound as if a URL-based system should work well for many temporary textures. It may also be a good short-term solution for handling baked textures but I suspect it's not the best long-term solution. That's because I'm beginning to realize that baked textures are conceptually very different from other temporary textures. Even though they change often, they're also far more precious. My baked textures are almost as important to my presentation as my displayed name which is why I'm starting to think of them as part of my agent data. I would like to have more direct control of the baked textures that I use to present myself to the world, even possibly to the point of being able to edit them in Photoshop and uploading to SL. I'm not saying that I want to do that today but I'm saying that I think it will be important to stop thinking of these as ordinary temporary textures. -Melinda From kelly at lindenlab.com Tue May 12 14:24:06 2009 From: kelly at lindenlab.com (Kelly) Date: Tue, 12 May 2009 14:24:06 -0700 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <4A09E632.7060007@superliminal.com> References: <4A0860D2.1070906@lindenlab.com> <20090512111726.GA7692@alinoe.com> <4A096DC7.10007@weblogsinc.com> <688F24A7-6C3D-4255-A07B-8DDE446E8841@gmail.com> <4A09CC78.8060600@Gmail.com> <4A09D6ED.7020108@superliminal.com> <4A09DB33.7070005@lindenlab.com> <4A09E632.7060007@superliminal.com> Message-ID: <4A09E8F6.6010109@lindenlab.com> > Kelly, > > Thank you for the additional background and technical details. It does > sound as if a URL-based system should work well for many temporary > textures. It may also be a good short-term solution for handling baked > textures but I suspect it's not the best long-term solution. That's > because I'm beginning to realize that baked textures are conceptually > very different from other temporary textures. Even though they change > often, they're also far more precious. My baked textures are almost as > important to my presentation as my displayed name which is why I'm > starting to think of them as part of my agent data. I would like to > have more direct control of the baked textures that I use to present > myself to the world, even possibly to the point of being able to edit > them in Photoshop and uploading to SL. I'm not saying that I want to > do that today but I'm saying that I think it will be important to stop > thinking of these as ordinary temporary textures. > > -Melinda I do not think there are any other baked textures in our system, although it is possible someone has piggy backed onto this feature for something else the entire setup is specific to avatar baked textures. In other words there is no such thing as an "ordinary temporary texture". While they are important, what makes them "temporary" is their unique property that they can be regenerated. If the baked texture is gone, which is expected to happen since cleanup of the texture files happens, hosts go down etc, we can ask the client to regenerate the textures. This changes if you can make your own custom baked textures, at which point they just aren't temporary any more - but they also aren't auto generated. Before 1.23 this was actually a semi reasonable behavior (assuming everything worked right) since you could still see avatars correctly if their baked textures weren't there - you would just composite on the fly for a couple of avatars. The problem is as you state though - these textures are very important and any hiccups in this system become very apparent and a huge concern. And we have never managed to get the system exactly perfect. - Kelly From tigrospottystripes at gmail.com Tue May 12 14:25:24 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 12 May 2009 18:25:24 -0300 Subject: [sldev] temporary textures controled by script? was: Re: Concept of "loaded avatar" was changed? In-Reply-To: <4A09E632.7060007@superliminal.com> References: <4A0860D2.1070906@lindenlab.com> <20090512111726.GA7692@alinoe.com> <4A096DC7.10007@weblogsinc.com> <688F24A7-6C3D-4255-A07B-8DDE446E8841@gmail.com> <4A09CC78.8060600@Gmail.com> <4A09D6ED.7020108@superliminal.com> <4A09DB33.7070005@lindenlab.com> <4A09E632.7060007@superliminal.com> Message-ID: <4A09E944.5050801@Gmail.com> In the discussion about baked textures the topic of HTTP textures facilitating temp textures came up, which made me think, is there the possibility of temporary script generated textures becoming avaiable? (perhaps somthing similar to what is proposed on http://jira.secondlife.com/browse/VWR-8943 ) From lev.neiman at gmail.com Tue May 12 14:31:10 2009 From: lev.neiman at gmail.com (Lev Neiman) Date: Tue, 12 May 2009 17:31:10 -0400 Subject: [sldev] Overcoming maximum size of IPC messages sent to SecondLife? Message-ID: Hello. I am running into a problem where SL exits when i attempt to send it large IPC message because of some buffer overflow. Is it possible to increase the size of this buffer, and thus increase the size of IPC message that can be sent to SL? Sincerely, Lev A. Neiman. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090512/59890c60/attachment.htm From melinda at superliminal.com Tue May 12 15:33:52 2009 From: melinda at superliminal.com (Melinda Green) Date: Tue, 12 May 2009 15:33:52 -0700 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <4A09E8F6.6010109@lindenlab.com> References: <4A0860D2.1070906@lindenlab.com> <20090512111726.GA7692@alinoe.com> <4A096DC7.10007@weblogsinc.com> <688F24A7-6C3D-4255-A07B-8DDE446E8841@gmail.com> <4A09CC78.8060600@Gmail.com> <4A09D6ED.7020108@superliminal.com> <4A09DB33.7070005@lindenlab.com> <4A09E632.7060007@superliminal.com> <4A09E8F6.6010109@lindenlab.com> Message-ID: <4A09F950.10507@superliminal.com> Kelly wrote: > >> Kelly, >> >> Thank you for the additional background and technical details. It >> does sound as if a URL-based system should work well for many >> temporary textures. It may also be a good short-term solution for >> handling baked textures but I suspect it's not the best long-term >> solution. That's because I'm beginning to realize that baked textures >> are conceptually very different from other temporary textures. Even >> though they change often, they're also far more precious. My baked >> textures are almost as important to my presentation as my displayed >> name which is why I'm starting to think of them as part of my agent >> data. I would like to have more direct control of the baked textures >> that I use to present myself to the world, even possibly to the point >> of being able to edit them in Photoshop and uploading to SL. I'm not >> saying that I want to do that today but I'm saying that I think it >> will be important to stop thinking of these as ordinary temporary >> textures. >> >> -Melinda > I do not think there are any other baked textures in our system, > although it is possible someone has piggy backed onto this feature for > something else the entire setup is specific to avatar baked textures. > In other words there is no such thing as an "ordinary temporary > texture". Avatar impostors are certainly another case of temporary texture, and emailed snapshots might be another. > While they are important, what makes them "temporary" is their unique > property that they can be regenerated. If the baked texture is gone, > which is expected to happen since cleanup of the texture files > happens, hosts go down etc, we can ask the client to regenerate the > textures. I don't buy the idea that they're temporary because they can be regenerated. That may *allow* them to be temporary, but doesn't imply to hat they need to be. > This changes if you can make your own custom baked textures, at which > point they just aren't temporary any more - but they also aren't auto > generated. Before 1.23 this was actually a semi reasonable behavior > (assuming everything worked right) since you could still see avatars > correctly if their baked textures weren't there - you would just > composite on the fly for a couple of avatars. I don't see what auto-generation has to do with this. The contract is that it's the viewer's responsibility to serve up baked textures in order to express how the user wants others to see them. I like the fact that the standard viewer can produce those textures but it could certainly serve them up from disk or URL just as easily, with no one else the wiser. Imagine the case where I might use very different clients at different times. I might use the standard viewer to produce baked textures, but later use the SLIM client to keep in touch with friends while I'm on the road. I'd certainly want my friends to see me with the textures that I'd previously produced, even though my simple IM client doesn't deal with textures at all and certainly wouldn't serve up baked textures. That suggests that for this all to work, the baked textures need to be able to be accessible wherever the rest of my agent data is found. > > The problem is as you state though - these textures are very important > and any hiccups in this system become very apparent and a huge > concern. And we have never managed to get the system exactly perfect. I agree, and I suspect that the reason we never got it right is because we never realized just how important baked textures are. The fact that they are composited from other textures suggested that this was just some sort of caching problem. When all the layer data for one avatar was available to all viewers, that was partly true but now we're beginning to realize that they are more than that and that this is not about caching. I think the right way to think about this problem is the same as we do with our profile photos. If a person's profile image is not available, then the viewer shows the stand-in question mark image which is the 2D equivalent of Ruth. I think it's great that the standard viewer is capable of automatically producing my baked textures but that doesn't change the fact that they are as much a part of my identity as my profile photo. More so probably. -Melinda From robla at lindenlab.com Tue May 12 17:52:13 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 12 May 2009 17:52:13 -0700 Subject: [sldev] [VWR, PATCH] VWR-2085: Hiding UI on Linux & http-texture branch In-Reply-To: <926a4b8e91f345320fc865d53ecb3781@localhost> References: <926a4b8e91f345320fc865d53ecb3781@localhost> Message-ID: <4A0A19BD.9070402@lindenlab.com> On 05/12/2009 06:52 AM, Opensource Obscure wrote: > This bug is old, has got patches and 23 votes and Linux > users would like to see it fixed: > > Ctrl-Alt-F1 Hide/Show UI Does Not Work Correctly Under Linux > http://jira.secondlife.com/browse/VWR-2085 > > Maybe this is a good idea for the http-texture viewer? > > I think it's an easy fix. Maybe changing all the shortcuts > in the viewer would make more sense, and I know this was > almost done; but there were no updates about this since > a few months, and IMHO other shortcuts can wait. This > feature is broken on Linux since 2 years and this is bad > for both machinima and immersive SL experience in general. > I'll add this to the merge queue, but let's get some clarity in VWR-2085 what the exact patch that's up for consideration. Thanks Rob From robla at lindenlab.com Tue May 12 17:58:18 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 12 May 2009 17:58:18 -0700 Subject: [sldev] [PATCH] Allow XUI to specificy tooltips for combo box listentries In-Reply-To: References: Message-ID: <4A0A1B2A.5080506@lindenlab.com> Given Aimee has already reviewed this and no one is screaming bloody murder here, I say go for it. Rob On 05/12/2009 07:50 AM, Robin Cornelius wrote: > Long over dew but patch at :- > > http://jira.secondlife.com/browse/VWR-13177 > > This patch complements Aimee's VWR-8008 which had feedback from the UI > team to add tooltips to the combo box items (something that did not > actually work then) > > is a patch that implements the feature of allowing the xui to specify > tool tips for the predefined entries in a combos list display. The > current tool tip display for a combo box is to display the same value > as in the list (for the list items NOT the combo box as a whole). > Which is not particularly helpful. > > It allows an XUI element to have a tool_tip attribute and > then display this tool_tip for this specific item. It only shows this > tool tip if it is defined else it falls back to the existing/default > behavior for listboxes on combos. > > Can some one give it a check before i commit to http-texture, thanks > > Robin > _______________________________________________ > 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 May 12 22:16:25 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 12 May 2009 22:16:25 -0700 Subject: [sldev] Experience so far with 2244 Message-ID: <4A0A57A9.8090300@lindenlab.com> Hi folks, Today I was able to run the 2244 viewer for most of the business day without too much incident. The main problems were an avatar rebaking problem which caused my avatar's head to be perpetually grey in everyone else's viewer (but fine in my own), and some problems with some avatars appearing transparent. Merov is working on merging the latest changes from 1.23 into the viewer now. One of the fixes that's part of that merge is a fix for VWR-12906 ("Changing outfits makes entire body, arms, hands of avatar disappear, makes face rezzing screwy"), so it seems likely that the problems I describe are not specific to the http-texture branch. Hard to know for sure though until that work is done. I've been keeping an eye out in the log for problems that might be related to the workaround fix in VWR-12775. Here's the log message you're likely to see in place of a crash: WARNING: callbackDecoded: DECODE FAILED: id = xxx, mFormattedImage is Null! I got 34 of those messages today. It'd make us feel a lot better if we knew what was really going on there, so we'd be happy to get some fresh eyes on the problem. That said, I wasn't able to find any issues that couldn't be explained away as possible 1.23 problems, so this may not be the most important thing to look at. Skimming through the crash reports, I see 6 crashes from today. 2 different residents reporting 3 crashes in OpenJPEG, but it doesn't look like we have good stack info there. One lingering case of VWR-12952. One watchdog-crash (i.e. a hang), which could be a lot of things. How has everyone else been doing with this viewer? If you haven't gotten it yet, check it out here: Linux: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2244/SecondLife-i686-1.23.0.2244.tar.bz2 Mac: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2244/SecondLife_1_23_0_2244_OSS.dmg Windows: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2244/Second_Life_1-23-0-2244_OSS_Setup.exe Rob From dynaturtle.cai at gmail.com Wed May 13 01:36:03 2009 From: dynaturtle.cai at gmail.com (Cai Xiao(dynaturtle)) Date: Wed, 13 May 2009 16:36:03 +0800 Subject: [sldev] problem with login to opensim Message-ID: <448f7bd20905130136h11977c6fu45c9956392cf1947@mail.gmail.com> Hey, guys, I am new to second life and I am trying to develop a robot using open metaverse. But I was confused with upload function. My program sometimes breaks with a exception as following: System.Exception was unhandled Message="NewFileAgentInventory capability is not currently available" Source="OpenMetaverse" StackTrace: at OpenMetaverse.InventoryManager.RequestCreateItemFromAsset(Byte[] data, String name, String description, AssetType assetType, InventoryType invType, UUID folderID, ProgressCallback progCallback, ItemCreatedFromAssetCallback callback) at OpenMetaverseStudy.PrimCreation.DoUpload(Byte[] UploadData, String fileName) in F:\graduate essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\PrimCreation.cs:line 98 at OpenMetaverseStudy.PrimCreation..ctor(OverlayStruct[] overlayArray) in F:\graduate essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\PrimCreation.cs:line 276 at OpenMetaverseStudy.Program.PrimAddFromDBDemo() in F:\graduate essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\Program.cs:line 123 at OpenMetaverseStudy.Program.Main(String[] args) in F:\graduate essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\Program.cs:line 182 at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args) at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart() InnerException: my code is as following: client.Inventory.RequestCreateItemFromAsset(UploadData, name, "Uploaded with Testclient", AssetType.Texture, InventoryType.Texture, client.Inventory.FindFolderForType(AssetType.Texture), delegate(CapsClient cclient, long bytesReceived, long bytesSent, long totalBytesToReceive, long totalBytesToSend) { if (bytesSent > 0) Console.WriteLine(String.Format("Texture upload: {0} / {1}", bytesSent, totalBytesToSend)); }, delegate(bool success, string status, UUID itemID, UUID assetID) { Console.WriteLine(String.Format( "RequestCreateItemFromAsset() returned: Success={0}, Status={1}, ItemID={2}, AssetID={3}", success, status, itemID, assetID)); UUIDTable.Add(name, assetID); TextureID = assetID; Console.WriteLine(String.Format("Upload took {0}", DateTime.Now.Subtract(start))); uploadCompleteEvents[completedUploadTexture].Set(); completedUploadTexture ++; } ); can anyone help me fix the problem? Thanks a lot. -- Department of Spatial Information Science&Technology, School of Earth&Space Science, Peking University ADD: Room 3028, Building 46, Peking University, Beijing, P.R. China Zip Code: 100871 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090513/aa8ef2d1/attachment-0001.htm From carlo at alinoe.com Wed May 13 04:26:37 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 13 May 2009 13:26:37 +0200 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <4A09D755.5050605@gmail.com> References: <4A0860D2.1070906@lindenlab.com> <20090512111726.GA7692@alinoe.com> <4A096DC7.10007@weblogsinc.com> <688F24A7-6C3D-4255-A07B-8DDE446E8841@gmail.com> <4A09CC78.8060600@Gmail.com> <4A09D755.5050605@gmail.com> Message-ID: <20090513112637.GA15223@alinoe.com> On Wed, May 13, 2009 at 06:08:53AM +1000, Tateru Nino wrote: > I don't recall ever seeing this problem with a companion walking or flying > across a sim border. Indeed. So, whatever happens then might be the Right Way to deal with this when one teleports. Anyway, to me it seems obvious that the only way to get this really seamless is by caching the baked textures of other avatars around you on the viewer, and reusing them after a TP if no other data is available. The downside of that is that in those cases that now we see a permanent cloud or grayness (because something really went wrong), current we ask that person to rebake their textures, but now would think we see them correctly. However that is ONLY a "problem" in the following case: - That avatar changed clothing / textures before following you; or since last meeting you. - The normal update fails. I'd think: concentrate on the latter, which is a bug to get rid of this "problem" then. Another way to tackle this new problem would be to add some hash (ie, in the form of three UUID's for the head/upper/lower parts) to the quick avatar data (that now contains their attachments; which seem to load always rather quick... quickly enough for me). Then my client would get those 'hash(es)' very quickly after a TP (as quick as currently the AO animations or attachments of the other avatar) and see that the clothing didn't change and therefore without any problem can start to show the cached clothing. Bottom line is: the viewer has to cache bake textures for other avatars until that avatar is out of sight too long. -- Carlo Wood From soft at lindenlab.com Wed May 13 05:29:31 2009 From: soft at lindenlab.com (Soft) Date: Wed, 13 May 2009 07:29:31 -0500 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it. http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From mwhite at leporidae.net Wed May 13 07:14:53 2009 From: mwhite at leporidae.net (Matt White) Date: Wed, 13 May 2009 10:14:53 -0400 Subject: [sldev] Experience so far with 2244 In-Reply-To: <4A0A57A9.8090300@lindenlab.com> References: <4A0A57A9.8090300@lindenlab.com> Message-ID: On Wed, May 13, 2009 at 1:16 AM, Rob Lanphier wrote: > One watchdog-crash (i.e. a hang), which could be a lot of things. That was me, yay! :) It crashed right at the end of the evening; I had been in-world for around five or six hours at the time, with all of the bells and whistles (including shadows) running. > How has everyone else been doing with this viewer? I've been running the OSS builds as they're posted here, but that brings up a question I have - is there a URL that automatically points to the latest OSS build? (Or a way to determine what the latest build is?) I'm not much of a C++ dev, and would most likely cause more problems than I fixed if I tried (haven't done C++ since college), but I'm perfectly willing to use a test viewer as my day-to-day viewer, provided there's a mainline viewer available to use "when it counts". I'm a tinkerer - I like finding bugs. I have no issues with downloading a new test viewer every day or every couple of days, as long as my preferences are kept between reinstalls, which the builds have been doing thus far. Waiting till a URL is posted here works, but if there's an automated one, I can just get in the habit of grabbing it every afternoon and banging on it for a few hours. -- Matt White / Bunny Halberd From zha.ewry at gmail.com Wed May 13 08:21:35 2009 From: zha.ewry at gmail.com (Zha Ewry) Date: Wed, 13 May 2009 11:21:35 -0400 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <20090513112637.GA15223@alinoe.com> References: <4A0860D2.1070906@lindenlab.com> <20090512111726.GA7692@alinoe.com> <4A096DC7.10007@weblogsinc.com> <688F24A7-6C3D-4255-A07B-8DDE446E8841@gmail.com> <4A09CC78.8060600@Gmail.com> <4A09D755.5050605@gmail.com> <20090513112637.GA15223@alinoe.com> Message-ID: <920d7d850905130821o10cd8a2m1de49131a52d9e96@mail.gmail.com> Note that when you cross a sim boundary, your client has already had a child agent in the new region for some time. (How long will depend on details such as your draw distance and speed approaching the crossing) Further, if you are crossing with another avatar, they too, have a child agent in the new region. I suspect this means that most of the material needed for your client to render the avatars will already be in hand in both the sim and your client as you cross. This is quite a bit different than the teleport case, where you both simultaneously establish new connections to the new sim. (Now why if you tp, and tp back you lose *so* much context, even cached, is another kettle of fish) ~ Zha On Wed, May 13, 2009 at 7:26 AM, Carlo Wood wrote: > On Wed, May 13, 2009 at 06:08:53AM +1000, Tateru Nino wrote: >> I don't recall ever seeing this problem with a companion walking or flying >> across a sim border. > > Indeed. So, whatever happens then might be the Right Way > to deal with this when one teleports. > > Anyway, to me it seems obvious that the only way to > get this really seamless is by caching the baked textures > of other avatars around you on the viewer, and reusing > them after a TP if no other data is available. > > The downside of that is that in those cases that now > we see a permanent cloud or grayness (because something > really went wrong), current we ask that person to > rebake their textures, but now would think we see > them correctly. However that is ONLY a "problem" in > the following case: > > - That avatar changed clothing / textures before > ? ?following you; or since last meeting you. > - The normal update fails. > > I'd think: concentrate on the latter, which is a bug > to get rid of this "problem" then. > Another way to tackle this new problem would be to > add some hash (ie, in the form of three UUID's for > the head/upper/lower parts) to the quick avatar data > (that now contains their attachments; which seem > to load always rather quick... quickly enough for me). > Then my client would get those 'hash(es)' very quickly > after a TP (as quick as currently the AO animations > or attachments of the other avatar) and see that > the clothing didn't change and therefore without > any problem can start to show the cached clothing. > > Bottom line is: the viewer has to cache bake textures > for other avatars until that avatar is out of sight > too long. > > -- > 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 anthonyrbundy at gmail.com Wed May 13 09:50:36 2009 From: anthonyrbundy at gmail.com (Anthony Bundy) Date: Wed, 13 May 2009 09:50:36 -0700 Subject: [sldev] problem with login to opensim In-Reply-To: <448f7bd20905130136h11977c6fu45c9956392cf1947@mail.gmail.com> References: <448f7bd20905130136h11977c6fu45c9956392cf1947@mail.gmail.com> Message-ID: <277a41080905130950o29de6efcu57f19c5fb374fb30@mail.gmail.com> You probably want to post this over on the openMV email list instead of here.http://openmv.org/cgi-bin/mailman/listinfo/libsl-dev Tony On Wed, May 13, 2009 at 1:36 AM, Cai Xiao(dynaturtle) < dynaturtle.cai at gmail.com> wrote: > Hey, guys, I am new to second life and I am trying to develop a robot > using open metaverse. But I was confused with upload function. My program > sometimes breaks with a exception as following: > System.Exception was unhandled Message="NewFileAgentInventory > capability is not currently available" > Source="OpenMetaverse" > StackTrace: > at OpenMetaverse.InventoryManager.RequestCreateItemFromAsset(Byte[] > data, String name, String description, AssetType assetType, InventoryType > invType, UUID folderID, ProgressCallback progCallback, > ItemCreatedFromAssetCallback callback) > at OpenMetaverseStudy.PrimCreation.DoUpload(Byte[] UploadData, > String fileName) in F:\graduate > essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\PrimCreation.cs:line > 98 > at OpenMetaverseStudy.PrimCreation..ctor(OverlayStruct[] > overlayArray) in F:\graduate > essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\PrimCreation.cs:line > 276 > at OpenMetaverseStudy.Program.PrimAddFromDBDemo() in F:\graduate > essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\Program.cs:line 123 > at OpenMetaverseStudy.Program.Main(String[] args) in F:\graduate > essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\Program.cs:line 182 > at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] > args) > at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence > assemblySecurity, String[] args) > at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() > at System.Threading.ThreadHelper.ThreadStart_Context(Object state) > at System.Threading.ExecutionContext.Run(ExecutionContext > executionContext, ContextCallback callback, Object state) > at System.Threading.ThreadHelper.ThreadStart() > InnerException: > > my code is as following: > client.Inventory.RequestCreateItemFromAsset(UploadData, name, > "Uploaded with Testclient", > AssetType.Texture, InventoryType.Texture, > client.Inventory.FindFolderForType(AssetType.Texture), > > delegate(CapsClient cclient, long bytesReceived, long > bytesSent, long totalBytesToReceive, long totalBytesToSend) > { > if (bytesSent > 0) > Console.WriteLine(String.Format("Texture > upload: {0} / {1}", bytesSent, totalBytesToSend)); > }, > > delegate(bool success, string status, UUID itemID, UUID > assetID) > { > Console.WriteLine(String.Format( > "RequestCreateItemFromAsset() returned: > Success={0}, Status={1}, ItemID={2}, AssetID={3}", > success, status, itemID, assetID)); > > UUIDTable.Add(name, assetID); > TextureID = assetID; > Console.WriteLine(String.Format("Upload took {0}", > DateTime.Now.Subtract(start))); > uploadCompleteEvents[completedUploadTexture].Set(); > completedUploadTexture ++; > } > ); > > can anyone help me fix the problem? > Thanks a lot. > > -- > Department of Spatial Information Science&Technology, > School of Earth&Space Science, Peking University > > ADD: Room 3028, Building 46, Peking University, Beijing, P.R. China > Zip Code: 100871 > > > _______________________________________________ > 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/20090513/91f6cee9/attachment.htm From gareth at litesim.com Wed May 13 11:17:07 2009 From: gareth at litesim.com (Gareth Nelson) Date: Wed, 13 May 2009 19:17:07 +0100 Subject: [sldev] problem with login to opensim In-Reply-To: <277a41080905130950o29de6efcu57f19c5fb374fb30@mail.gmail.com> References: <448f7bd20905130136h11977c6fu45c9956392cf1947@mail.gmail.com> <277a41080905130950o29de6efcu57f19c5fb374fb30@mail.gmail.com> Message-ID: <61dbdd7d0905131117g6baf7e49ua34e1256aad72913@mail.gmail.com> This bit is perhaps relevant: Message="NewFileAgentInventory capability is not currently available" Has this cap actually been removed recently? On Wed, May 13, 2009 at 5:50 PM, Anthony Bundy wrote: > You probably want to post this over on the openMV email list instead of > here. > http://openmv.org/cgi-bin/mailman/listinfo/libsl-dev > Tony > > On Wed, May 13, 2009 at 1:36 AM, Cai Xiao(dynaturtle) > wrote: >> >> Hey, guys, >> ?? ? I am new to second life and I am trying to develop a robot using open >> metaverse. But I was confused with upload function. My program sometimes >> breaks with a exception as following: >> ?? ?System.Exception was unhandled >> ??Message="NewFileAgentInventory capability is not currently available" >> ??Source="OpenMetaverse" >> ??StackTrace: >> ?? ? ? at OpenMetaverse.InventoryManager.RequestCreateItemFromAsset(Byte[] >> data, String name, String description, AssetType assetType, InventoryType >> invType, UUID folderID, ProgressCallback progCallback, >> ItemCreatedFromAssetCallback callback) >> ?? ? ? at OpenMetaverseStudy.PrimCreation.DoUpload(Byte[] UploadData, >> String fileName) in F:\graduate >> essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\PrimCreation.cs:line >> 98 >> ?? ? ? at OpenMetaverseStudy.PrimCreation..ctor(OverlayStruct[] >> overlayArray) in F:\graduate >> essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\PrimCreation.cs:line >> 276 >> ?? ? ? at OpenMetaverseStudy.Program.PrimAddFromDBDemo() in F:\graduate >> essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\Program.cs:line 123 >> ?? ? ? at OpenMetaverseStudy.Program.Main(String[] args) in F:\graduate >> essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\Program.cs:line 182 >> ?? ? ? at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] >> args) >> ?? ? ? at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence >> assemblySecurity, String[] args) >> ?? ? ? at >> Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() >> ?? ? ? at System.Threading.ThreadHelper.ThreadStart_Context(Object state) >> ?? ? ? at System.Threading.ExecutionContext.Run(ExecutionContext >> executionContext, ContextCallback callback, Object state) >> ?? ? ? at System.Threading.ThreadHelper.ThreadStart() >> ??InnerException: >> my code is as following: >> ?? ? ? client.Inventory.RequestCreateItemFromAsset(UploadData, name, >> "Uploaded with Testclient", >> ?? ? ? ? ? ? ? ? ? ?AssetType.Texture, InventoryType.Texture, >> client.Inventory.FindFolderForType(AssetType.Texture), >> ?? ? ? ? ? ? ? ? ? ?delegate(CapsClient cclient, long bytesReceived, long >> bytesSent, long totalBytesToReceive, long totalBytesToSend) >> ?? ? ? ? ? ? ? ? ? ?{ >> ?? ? ? ? ? ? ? ? ? ? ? ?if (bytesSent > 0) >> ?? ? ? ? ? ? ? ? ? ? ? ? ? ?Console.WriteLine(String.Format("Texture >> upload: {0} / {1}", bytesSent, totalBytesToSend)); >> ?? ? ? ? ? ? ? ? ? ?}, >> ?? ? ? ? ? ? ? ? ? ?delegate(bool success, string status, UUID itemID, >> UUID assetID) >> ?? ? ? ? ? ? ? ? ? ?{ >> ?? ? ? ? ? ? ? ? ? ? ? ?Console.WriteLine(String.Format( >> ?? ? ? ? ? ? ? ? ? ? ? ? ? ?"RequestCreateItemFromAsset() returned: >> Success={0}, Status={1}, ItemID={2}, AssetID={3}", >> ?? ? ? ? ? ? ? ? ? ? ? ? ? ?success, status, itemID, assetID)); >> >> ?? ? ? ? ? ? ? ? ? ? ? ?UUIDTable.Add(name, assetID); >> ?? ? ? ? ? ? ? ? ? ? ? ?TextureID = assetID; >> ?? ? ? ? ? ? ? ? ? ? ? ?Console.WriteLine(String.Format("Upload took {0}", >> DateTime.Now.Subtract(start))); >> >> ?uploadCompleteEvents[completedUploadTexture].Set(); >> ?? ? ? ? ? ? ? ? ? ? ? ?completedUploadTexture ++; >> ?? ? ? ? ? ? ? ? ? ?} >> ?? ? ? ? ? ? ? ?); >> can anyone help me fix the problem? >> Thanks a lot. >> -- >> Department of Spatial Information Science&Technology, >> School of Earth&Space Science, Peking University >> >> ADD: Room 3028, Building 46, Peking University, Beijing, P.R. China >> Zip Code: 100871 >> >> >> _______________________________________________ >> 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 tateru.nino at gmail.com Wed May 13 12:27:28 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu, 14 May 2009 05:27:28 +1000 Subject: [sldev] Concept of "loaded avatar" was changed? In-Reply-To: <920d7d850905130821o10cd8a2m1de49131a52d9e96@mail.gmail.com> References: <4A0860D2.1070906@lindenlab.com> <20090512111726.GA7692@alinoe.com> <4A096DC7.10007@weblogsinc.com> <688F24A7-6C3D-4255-A07B-8DDE446E8841@gmail.com> <4A09CC78.8060600@Gmail.com> <4A09D755.5050605@gmail.com> <20090513112637.GA15223@alinoe.com> <920d7d850905130821o10cd8a2m1de49131a52d9e96@mail.gmail.com> Message-ID: <4A0B1F20.9090403@gmail.com> Absolutely, Zha - I was just thinking that myself. As I've observed previously, a teleport seems to somehow trigger quite a bit of discard. That might not be what's going on, but that's how it feels. Zha Ewry wrote: > Note that when you cross a sim boundary, your client has already had a > child agent in the new region for some time. (How long will depend on > details such as your draw distance and speed approaching the crossing) > Further, if you are crossing with another avatar, they too, have a > child agent in the new region. I suspect this means that most of the > material needed for your client to render the avatars will already be > in hand in both the sim and your client as you cross. This is quite a > bit different than the teleport case, where you both simultaneously > establish new connections to the new sim. (Now why if you tp, and tp > back you lose *so* much context, even cached, is another kettle of > fish) > > ~ Zha > > On Wed, May 13, 2009 at 7:26 AM, Carlo Wood wrote: > >> On Wed, May 13, 2009 at 06:08:53AM +1000, Tateru Nino wrote: >> >>> I don't recall ever seeing this problem with a companion walking or flying >>> across a sim border. >>> >> Indeed. So, whatever happens then might be the Right Way >> to deal with this when one teleports. >> >> Anyway, to me it seems obvious that the only way to >> get this really seamless is by caching the baked textures >> of other avatars around you on the viewer, and reusing >> them after a TP if no other data is available. >> >> The downside of that is that in those cases that now >> we see a permanent cloud or grayness (because something >> really went wrong), current we ask that person to >> rebake their textures, but now would think we see >> them correctly. However that is ONLY a "problem" in >> the following case: >> >> - That avatar changed clothing / textures before >> following you; or since last meeting you. >> - The normal update fails. >> >> I'd think: concentrate on the latter, which is a bug >> to get rid of this "problem" then. >> Another way to tackle this new problem would be to >> add some hash (ie, in the form of three UUID's for >> the head/upper/lower parts) to the quick avatar data >> (that now contains their attachments; which seem >> to load always rather quick... quickly enough for me). >> Then my client would get those 'hash(es)' very quickly >> after a TP (as quick as currently the AO animations >> or attachments of the other avatar) and see that >> the clothing didn't change and therefore without >> any problem can start to show the cached clothing. >> >> Bottom line is: the viewer has to cache bake textures >> for other avatars until that avatar is out of sight >> too long. >> >> -- >> 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 >> >> > > -- Tateru Nino http://www.massively.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090514/6a5f7ed1/attachment.htm From robla at lindenlab.com Wed May 13 13:57:47 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 13 May 2009 13:57:47 -0700 Subject: [sldev] Finding the latest build (Re: Experience so far with 2244) In-Reply-To: References: <4A0A57A9.8090300@lindenlab.com> Message-ID: <4A0B344B.9050804@lindenlab.com> On 05/13/2009 07:14 AM, Matt White wrote: > I've been running the OSS builds as they're posted here, but that > brings up a question I have - is there a URL that automatically points > to the latest OSS build? (Or a way to determine what the latest build > is?) > Hi Matt, Glad to have you working on this. If you want the absolute newest bits, subscribe to this mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits Here's the notification flow you should see: 1. Commits to the projects/2009/http-texture branch, like this one: https://lists.secondlife.com/pipermail/sldev-commits/2009-May/002610.html 2. Some time later, someone will manually fire off a build to pick up the changes since the last build. When that build completes, you'll either see a successful build notification, like this one: https://lists.secondlife.com/pipermail/sldev-commits/2009-May/002612.html ...or a failed build notice, like this one: https://lists.secondlife.com/pipermail/sldev-commits/2009-May/002580.html If you notice there's some older changes for which don't appear to have been built yet, hop onto irc.efnet.org #opensl and ask one of the Lindens (me: llrobla) to fire off a build. There are several of us that can do that, and it only takes a few pokes at a web page for any of us to do it. 3. Generally, there's someone that pounces on the build right away. If they have a reasonably good experience with it, they'll update the latest build page here: https://wiki.secondlife.com/wiki/Open_Source_Portal If you'd like to update that page, the place to do the updating is actually here: https://wiki.secondlife.com/wiki/Template:Open_Source_Portal/Featured Please only do this after you've successfully run the build yourself and verified that it at least doesn't crash on startup on your favorite platform. To date, only Merov and I have updated this, but I don't think others should be shy about doing so. 4. Occasionally, someone will then send email to sldev@ about the build. We'd love to have your help in testing these builds as they roll off the end of the assembly line! Rob From mike.dickson at hp.com Wed May 13 15:14:03 2009 From: mike.dickson at hp.com (Mike Dickson) Date: Wed, 13 May 2009 17:14:03 -0500 Subject: [sldev] Building the client for Fedora 11 In-Reply-To: <4A0B344B.9050804@lindenlab.com> References: <4A0A57A9.8090300@lindenlab.com> <4A0B344B.9050804@lindenlab.com> Message-ID: <1242252843.3700.42.camel@localhost.localdomain> Fedora 11 (in RC now, about a week to release) has upgraded to Firefox 3.5 and blows up fairly quickly with an unresolved symbol error: bin/do-not-directly-run-secondlife-bin: /home/mdickson/Applications/SecondLife-i686-1.22.11.113941/app_settings/mozilla-runtime-linux-i686/libfreebl3.so: version `NSSRAWHASH_3.12.3' not found (required by /lib/libcrypt.so.1) How plausible is a build from sources using the native libraries as a fix to this? Or is the mozilla runtime dependencies in the SL tree looking for this specific version? I've not waded into the client up to now but sometime in the future I'd like to upgrade to F11 and it would be nice to help squash this... Thanks in advance for any guidance. Mike From mwhite at leporidae.net Wed May 13 16:18:27 2009 From: mwhite at leporidae.net (Matt White) Date: Wed, 13 May 2009 19:18:27 -0400 Subject: [sldev] Finding the latest build (Re: Experience so far with 2244) In-Reply-To: <4A0B344B.9050804@lindenlab.com> References: <4A0A57A9.8090300@lindenlab.com> <4A0B344B.9050804@lindenlab.com> Message-ID: On Wed, May 13, 2009 at 4:57 PM, Rob Lanphier wrote: > Glad to have you working on this. ?If you want the absolute newest bits, > subscribe to this mailing list: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits > > Here's the notification flow you should see: > > 1. ?Commits to the projects/2009/http-texture branch, like this one: > https://lists.secondlife.com/pipermail/sldev-commits/2009-May/002610.html > > 2. ?Some time later, someone will manually fire off a build to pick up > the changes since the last build. ?When that build completes, you'll > either see a successful build notification, like this one: > https://lists.secondlife.com/pipermail/sldev-commits/2009-May/002612.html > > ...or a failed build notice, like this one: > https://lists.secondlife.com/pipermail/sldev-commits/2009-May/002580.html Excellent. I've subscribed to the list, and I bet I can write a GMail filter to throw the "Successful Build" messages to my inbox with a flag set. > If you notice there's some older changes for which don't appear to have > been built yet, hop onto irc.efnet.org #opensl and ask one of the > Lindens (me: llrobla) to fire off a build. ?There are several of us that > can do that, and it only takes a few pokes at a web page for any of us > to do it. Will do. > We'd love to have your help in testing these builds as they roll off the > end of the assembly line! Glad to help out. I'm very active in-world (5-6 hours a night in world usually, more on weekends) and not scared of a viewer crash. :) Vista64 platform, and I always grab the latest nVidia drivers when they are available. Seems like most of the crashes on the release clients can be fixed by making sure your video drivers are current. -- Matt White / Bunny Halberd From robla at lindenlab.com Wed May 13 17:17:25 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 13 May 2009 17:17:25 -0700 Subject: [sldev] Building the client for Fedora 11 In-Reply-To: <1242252843.3700.42.camel@localhost.localdomain> References: <4A0A57A9.8090300@lindenlab.com><4A0B344B.9050804@linden lab.com> <1242252843.3700.42.camel@localhost.localdomain> Message-ID: <4A0B6315.8030409@lindenlab.com> On 05/13/2009 03:14 PM, Mike Dickson wrote: > Fedora 11 (in RC now, about a week to release) has upgraded to Firefox > 3.5 and blows up fairly quickly with an unresolved symbol error: > > bin/do-not-directly-run-secondlife-bin: /home/mdickson/Applications/SecondLife-i686-1.22.11.113941/app_settings/mozilla-runtime-linux-i686/libfreebl3.so: version `NSSRAWHASH_3.12.3' not found (required by /lib/libcrypt.so.1) > > How plausible is a build from sources using the native libraries as a > fix to this? Or is the mozilla runtime dependencies in the SL tree > looking for this specific version? I've not waded into the client up to > now but sometime in the future I'd like to upgrade to F11 and it would > be nice to help squash this... > > Thanks in advance for any guidance. > Upgrading to use the Firefox 3.5 libraries would be extremely difficult, from everything I understand. Basically, the Mozilla APIs we use are not supported interfaces, and change from version-to-version. My understanding is that every upgrade requires a major reworking in order to reestablish compatibility. We're planning on moving to WebKit, which provides a stable API for the type of embedding we do. Details on our work so far are available here: https://wiki.secondlife.com/wiki/QtWebKit Rob From robla at lindenlab.com Wed May 13 17:38:23 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 13 May 2009 17:38:23 -0700 Subject: [sldev] A brief history lesson on our branches (Re:http-texture branch) In-Reply-To: <49F31778.4040202@boroon.dasgupta.ch> References: <12120960-2BAB-4C82-A87A-F9EBC2B320E7@lindenlab.com><200904241805.26410.lists.secondlife.com@trap.wereanimal.net> <2A947AA4-63AE-4153-987E-EA13FD72163A@lindenlab.com><49F26219.4070803@lindenlab.com> <49F31778.4040202@boroon.dasgupta.ch> Message-ID: <4A0B67FF.6090003@lindenlab.com> Digging back through some of the email I didn't get to because of my vacation.... On 04/25/2009 07:00 AM, Boroondas Gupte wrote: > Rob Lanphier schrieb: > >> Some enterprising soul may want to update this page to reflect the new >> world order, since it's been a while since its seen an update: >> https://wiki.secondlife.com/wiki/Source_branches >> > OK, I've done that: > https://wiki.secondlife.com/wiki/Source_branches#Current_repository_structure > Please correct any misconceptions I might have included. (Bonus points > if someone cleans up the old stuff still there) > Thanks! > What is still missing but would be nice to have documented: Is there any > rule about what branches will go directly to > linden/branches/ (e.g. > http://svn.secondlife.com/svn/linden/branches/render-pipeline/) and what > to linden/braches// (e.g. > http://svn.secondlife.com/svn/linden/branches/2009/http-texture/)? > Persistent branches that are expected to have development effort indefinitely go in the top level, as well as branches corresponding to released versions of the code. Branches that we know aren't going to be under active development go in the year-based directory. Some branches that we expect to live on indefinitely we may still put in a year-based directory, because until it's been around a couple years, we can't know for sure it's going to remain relevant. The concept was borrowed from here: http://www.w3.org/Provider/Style/URI While the source code is not really a website, it's a great anti-crufting measure to stuff things into year based directories from the get-go. Since there are going to be cases where people deep link to svn.secondlife.com in emails and on websites, it's still kinda rude to move things around too much. Rob From dynaturtle.cai at gmail.com Wed May 13 18:31:53 2009 From: dynaturtle.cai at gmail.com (Cai Xiao(dynaturtle)) Date: Thu, 14 May 2009 09:31:53 +0800 Subject: [sldev] problem with login to opensim In-Reply-To: <61dbdd7d0905131117g6baf7e49ua34e1256aad72913@mail.gmail.com> References: <448f7bd20905130136h11977c6fu45c9956392cf1947@mail.gmail.com> <277a41080905130950o29de6efcu57f19c5fb374fb30@mail.gmail.com> <61dbdd7d0905131117g6baf7e49ua34e1256aad72913@mail.gmail.com> Message-ID: <448f7bd20905131831v2ae4fc37nf188ebb22c7d2bdf@mail.gmail.com> Actually, the cap is available. And the exception sometimes appears.I debug the program, and it shows exception is caused by " if (_Client.Network.CurrentSim == null || _Client.Network.CurrentSim.Caps == null) throw new Exception("NewFileAgentInventory capability is not currently available");" the _Client.Network.CurrentSim is null actually On Thu, May 14, 2009 at 2:17 AM, Gareth Nelson wrote: > This bit is perhaps relevant: > Message="NewFileAgentInventory capability is not currently available" > > Has this cap actually been removed recently? > > On Wed, May 13, 2009 at 5:50 PM, Anthony Bundy > wrote: > > You probably want to post this over on the openMV email list instead of > > here. > > http://openmv.org/cgi-bin/mailman/listinfo/libsl-dev > > Tony > > > > On Wed, May 13, 2009 at 1:36 AM, Cai Xiao(dynaturtle) > > wrote: > >> > >> Hey, guys, > >> I am new to second life and I am trying to develop a robot using > open > >> metaverse. But I was confused with upload function. My program sometimes > >> breaks with a exception as following: > >> System.Exception was unhandled > >> Message="NewFileAgentInventory capability is not currently available" > >> Source="OpenMetaverse" > >> StackTrace: > >> at > OpenMetaverse.InventoryManager.RequestCreateItemFromAsset(Byte[] > >> data, String name, String description, AssetType assetType, > InventoryType > >> invType, UUID folderID, ProgressCallback progCallback, > >> ItemCreatedFromAssetCallback callback) > >> at OpenMetaverseStudy.PrimCreation.DoUpload(Byte[] UploadData, > >> String fileName) in F:\graduate > >> > essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\PrimCreation.cs:line > >> 98 > >> at OpenMetaverseStudy.PrimCreation..ctor(OverlayStruct[] > >> overlayArray) in F:\graduate > >> > essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\PrimCreation.cs:line > >> 276 > >> at OpenMetaverseStudy.Program.PrimAddFromDBDemo() in F:\graduate > >> essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\Program.cs:line > 123 > >> at OpenMetaverseStudy.Program.Main(String[] args) in F:\graduate > >> essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\Program.cs:line > 182 > >> at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] > >> args) > >> at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence > >> assemblySecurity, String[] args) > >> at > >> Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() > >> at System.Threading.ThreadHelper.ThreadStart_Context(Object > state) > >> at System.Threading.ExecutionContext.Run(ExecutionContext > >> executionContext, ContextCallback callback, Object state) > >> at System.Threading.ThreadHelper.ThreadStart() > >> InnerException: > >> my code is as following: > >> client.Inventory.RequestCreateItemFromAsset(UploadData, name, > >> "Uploaded with Testclient", > >> AssetType.Texture, InventoryType.Texture, > >> client.Inventory.FindFolderForType(AssetType.Texture), > >> delegate(CapsClient cclient, long bytesReceived, > long > >> bytesSent, long totalBytesToReceive, long totalBytesToSend) > >> { > >> if (bytesSent > 0) > >> Console.WriteLine(String.Format("Texture > >> upload: {0} / {1}", bytesSent, totalBytesToSend)); > >> }, > >> delegate(bool success, string status, UUID itemID, > >> UUID assetID) > >> { > >> Console.WriteLine(String.Format( > >> "RequestCreateItemFromAsset() returned: > >> Success={0}, Status={1}, ItemID={2}, AssetID={3}", > >> success, status, itemID, assetID)); > >> > >> UUIDTable.Add(name, assetID); > >> TextureID = assetID; > >> Console.WriteLine(String.Format("Upload took > {0}", > >> DateTime.Now.Subtract(start))); > >> > >> uploadCompleteEvents[completedUploadTexture].Set(); > >> completedUploadTexture ++; > >> } > >> ); > >> can anyone help me fix the problem? > >> Thanks a lot. > >> -- > >> Department of Spatial Information Science&Technology, > >> School of Earth&Space Science, Peking University > >> > >> ADD: Room 3028, Building 46, Peking University, Beijing, P.R. China > >> Zip Code: 100871 > >> > >> > >> _______________________________________________ > >> 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 > > > -- Department of Spatial Information Science&Technology, School of Earth&Space Science, Peking University ADD: Room 3028, Building 46, Peking University, Beijing, P.R. China Zip Code: 100871 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090514/6628bf93/attachment-0001.htm From gareth at litesim.com Thu May 14 02:43:43 2009 From: gareth at litesim.com (Gareth Nelson) Date: Thu, 14 May 2009 10:43:43 +0100 Subject: [sldev] problem with login to opensim In-Reply-To: <448f7bd20905131831v2ae4fc37nf188ebb22c7d2bdf@mail.gmail.com> References: <448f7bd20905130136h11977c6fu45c9956392cf1947@mail.gmail.com> <277a41080905130950o29de6efcu57f19c5fb374fb30@mail.gmail.com> <61dbdd7d0905131117g6baf7e49ua34e1256aad72913@mail.gmail.com> <448f7bd20905131831v2ae4fc37nf188ebb22c7d2bdf@mail.gmail.com> Message-ID: <61dbdd7d0905140243g7e932741wcf895c5714c2eb79@mail.gmail.com> In that case, i'd take this to the openmv mailing list and not this one, at first glance it looks likely to be a bug in libopenmv's handling of the current caps. On Thu, May 14, 2009 at 2:31 AM, Cai Xiao(dynaturtle) wrote: > Actually, the cap is?available. ?And the exception sometimes appears. > I debug the program, and it shows exception is caused by > "?? ?if (_Client.Network.CurrentSim == null || > _Client.Network.CurrentSim.Caps == null) > ?? ? ? ? ? ? ? ?throw new Exception("NewFileAgentInventory capability is not > currently available");" > the _Client.Network.CurrentSim is null actually > On Thu, May 14, 2009 at 2:17 AM, Gareth Nelson wrote: >> >> This bit is perhaps relevant: >> Message="NewFileAgentInventory capability is not currently available" >> >> Has this cap actually been removed recently? >> >> On Wed, May 13, 2009 at 5:50 PM, Anthony Bundy >> wrote: >> > You probably want to post this over on the openMV email list instead of >> > here. >> > http://openmv.org/cgi-bin/mailman/listinfo/libsl-dev >> > Tony >> > >> > On Wed, May 13, 2009 at 1:36 AM, Cai Xiao(dynaturtle) >> > wrote: >> >> >> >> Hey, guys, >> >> ?? ? I am new to second life and I am trying to develop a robot using >> >> open >> >> metaverse. But I was confused with upload function. My program >> >> sometimes >> >> breaks with a exception as following: >> >> ?? ?System.Exception was unhandled >> >> ??Message="NewFileAgentInventory capability is not currently available" >> >> ??Source="OpenMetaverse" >> >> ??StackTrace: >> >> ?? ? ? at >> >> OpenMetaverse.InventoryManager.RequestCreateItemFromAsset(Byte[] >> >> data, String name, String description, AssetType assetType, >> >> InventoryType >> >> invType, UUID folderID, ProgressCallback progCallback, >> >> ItemCreatedFromAssetCallback callback) >> >> ?? ? ? at OpenMetaverseStudy.PrimCreation.DoUpload(Byte[] UploadData, >> >> String fileName) in F:\graduate >> >> >> >> essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\PrimCreation.cs:line >> >> 98 >> >> ?? ? ? at OpenMetaverseStudy.PrimCreation..ctor(OverlayStruct[] >> >> overlayArray) in F:\graduate >> >> >> >> essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\PrimCreation.cs:line >> >> 276 >> >> ?? ? ? at OpenMetaverseStudy.Program.PrimAddFromDBDemo() in F:\graduate >> >> essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\Program.cs:line >> >> 123 >> >> ?? ? ? at OpenMetaverseStudy.Program.Main(String[] args) in F:\graduate >> >> essay\3dpku\trunk\OpenMetaverseStudy\OpenMetaverseStudy\Program.cs:line >> >> 182 >> >> ?? ? ? at System.AppDomain._nExecuteAssembly(Assembly assembly, >> >> String[] >> >> args) >> >> ?? ? ? at System.AppDomain.ExecuteAssembly(String assemblyFile, >> >> Evidence >> >> assemblySecurity, String[] args) >> >> ?? ? ? at >> >> Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() >> >> ?? ? ? at System.Threading.ThreadHelper.ThreadStart_Context(Object >> >> state) >> >> ?? ? ? at System.Threading.ExecutionContext.Run(ExecutionContext >> >> executionContext, ContextCallback callback, Object state) >> >> ?? ? ? at System.Threading.ThreadHelper.ThreadStart() >> >> ??InnerException: >> >> my code is as following: >> >> ?? ? ? client.Inventory.RequestCreateItemFromAsset(UploadData, name, >> >> "Uploaded with Testclient", >> >> ?? ? ? ? ? ? ? ? ? ?AssetType.Texture, InventoryType.Texture, >> >> client.Inventory.FindFolderForType(AssetType.Texture), >> >> ?? ? ? ? ? ? ? ? ? ?delegate(CapsClient cclient, long bytesReceived, >> >> long >> >> bytesSent, long totalBytesToReceive, long totalBytesToSend) >> >> ?? ? ? ? ? ? ? ? ? ?{ >> >> ?? ? ? ? ? ? ? ? ? ? ? ?if (bytesSent > 0) >> >> ?? ? ? ? ? ? ? ? ? ? ? ? ? ?Console.WriteLine(String.Format("Texture >> >> upload: {0} / {1}", bytesSent, totalBytesToSend)); >> >> ?? ? ? ? ? ? ? ? ? ?}, >> >> ?? ? ? ? ? ? ? ? ? ?delegate(bool success, string status, UUID itemID, >> >> UUID assetID) >> >> ?? ? ? ? ? ? ? ? ? ?{ >> >> ?? ? ? ? ? ? ? ? ? ? ? ?Console.WriteLine(String.Format( >> >> ?? ? ? ? ? ? ? ? ? ? ? ? ? ?"RequestCreateItemFromAsset() returned: >> >> Success={0}, Status={1}, ItemID={2}, AssetID={3}", >> >> ?? ? ? ? ? ? ? ? ? ? ? ? ? ?success, status, itemID, assetID)); >> >> >> >> ?? ? ? ? ? ? ? ? ? ? ? ?UUIDTable.Add(name, assetID); >> >> ?? ? ? ? ? ? ? ? ? ? ? ?TextureID = assetID; >> >> ?? ? ? ? ? ? ? ? ? ? ? ?Console.WriteLine(String.Format("Upload took >> >> {0}", >> >> DateTime.Now.Subtract(start))); >> >> >> >> ?uploadCompleteEvents[completedUploadTexture].Set(); >> >> ?? ? ? ? ? ? ? ? ? ? ? ?completedUploadTexture ++; >> >> ?? ? ? ? ? ? ? ? ? ?} >> >> ?? ? ? ? ? ? ? ?); >> >> can anyone help me fix the problem? >> >> Thanks a lot. >> >> -- >> >> Department of Spatial Information Science&Technology, >> >> School of Earth&Space Science, Peking University >> >> >> >> ADD: Room 3028, Building 46, Peking University, Beijing, P.R. China >> >> Zip Code: 100871 >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > > > > > -- > Department of Spatial Information Science&Technology, > School of Earth&Space Science, Peking University > > ADD: Room 3028, Building 46, Peking University, Beijing, P.R. China > Zip Code: 100871 > > From tofu.linden at lindenlab.com Thu May 14 06:32:20 2009 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu, 14 May 2009 14:32:20 +0100 Subject: [sldev] would this help with increasing the apparent number oflight sources at all? In-Reply-To: <9bb32d430905110057v6ef18b43o16a7c3c430fc4bdd@mail.gmail.com> References: <4A03B2DE.8030602@Gmail.com><0016361645a5633eaa04695f54de@google.com> <9bb32d430905110057v6ef18b43o16a7c3c430fc4bdd@mail.gmail.com> Message-ID: <4A0C1D64.6010500@lindenlab.com> Right, that disables all shadow calculation. What you end up with is something that generally looks and performs similarly to the Atmospheric Shaders pipeline, except that you get many many many more lights and other lighting improvements (hooray). n.b. though, all of the RenderDeferred stuff is extremely experimental and subject to rapid change and breakage. I'm talking about the render-pipeline branch, which has long-since obsoleted the earlier version of these changes which were known as 'shadow-draft'. Ambrosia wrote: > You can use it without shadows, that's the beauty. Once RenderUseFBO > and RenderDeferred are enabled, simply deactiavate > RenderSunShdaows(?). I think that was the debug param. And voila, you > have the deferred renderer without any shadowing. I however don't know > if shadow calculations aren't still going on in the background, and > this simply turns off the rendering of those. > > > On Fri, May 8, 2009 at 06:47, wrote: >> Theres already a system for infinite light sources in the shadow-draft >> client. Why not just use that minus shadows? I have been meaning to ask this >> for a long time. >> _______________________________________________ >> 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 May 14 09:39:47 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 14 May 2009 09:39:47 -0700 Subject: [sldev] Crash reports analysis [http-texture builds] In-Reply-To: References: <9E20290B-FB30-423B-A266-EF6ECF480E95@lindenlab.com> Message-ID: <4A0C4953.4050306@lindenlab.com> Reviving old discussion..... On 04/30/2009 03:00 AM, Robin Cornelius wrote: > On Thu, Apr 30, 2009 at 7:23 AM, Philippe Bossut (Merov Linden) > wrote: > >> The OpenJPEG crashers are concerning. There are unfortunately little >> info in the stack trace and I haven't myself experienced that one. >> What's strange is that I looked into the other viewers crash logs >> (thousands of them) and it doesn't surface at all in their crashers. >> May be of note: our 2 crashers happen on Vista. Does this ring a bell >> to anyone? >> > I surprised that that you have not had more reports on this. Certainly > some of us have seen this fairly frequently who are building ourselves > and it usually is triggers from the LLImageJ2COJ::getMetadata() during > some where in opj_image_destroywhen a wild pointer is freed (possible > also related to a bad image being fed to decode). This is fixed in > openjpeg SVN and i think those of us on #opensl who are building > http-texture already have this patched (or at least a good few do). > Although its possible (I would need to confirm) that we see it because > this was introduced in openjpeg 1.3 and LL are still on 1.2 internally > and also this could explain why we don't see any other crashes here. > > Looking at http://www.openjpeg.org/websvn/filedetails.php?repname=OpenJpeg&path=%2Ftrunk%2Flibopenjpeg%2Fimage.c&rev=0&sc=0 > > the opj_free(image->comps); > > is the offending line, note in the SVN web view the structures are > allocated with opj_calloc() where as the older code uses opj_malloc() > which does not null the pointers. > > There may also need to be some viewer sanity checking here as well as > various image-> members are used in LLImageJ2COJ::getMetadata() and > although i've not see a crash directly because of their use after > patching openjpeg its probably worth investigating to ensure no edge > case is creeping in here. > Well....this seems like a concerning thing to let just lay around. I've got a few questions about this: 1. The SLDev Viewer should be using KDU by default. Is there some functionality (e.g. the new map) that uses OpenJPEG by default, even if KDU is available? 2. Is there something in JIRA about this particular issue already? 3. Since this bug isn't fixed in OpenJPEG 1.3, but the release timeline for OpenJPEG 2.0 doesn't look clear, what would be the odds of convincing the OpenJPEG team to ship an OpenJPEG 1.3.1. We've got a strong preference to stick with releases rather than svn snapshots. 4. If an OpenJPEG 1.3.1 isn't in the cards, it seems like we should suck it up and patch our OpenJPEG. Right? 5. Is the currently shipping SLDev Viewer build still on 1.2? Some of these I'll be able to research myself, but I also know there are many of you who know this off the tops of your respective heads. Rob From aimee.trescothick at gmail.com Thu May 14 10:48:01 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Thu, 14 May 2009 18:48:01 +0100 Subject: [sldev] [Patch] VWR-6918 Tools menu option to hide selection outlines Message-ID: <80E59499-B3E3-4EF4-BDEA-CB746FAAC1E1@gmail.com> I have just attached a patch to VWR-6918 adding an option to the tools menu which make it possible to hide the selection highlights while building. This is of great use while using very small prims, or aligning textures. The current work around (http://wiki.secondlife.com/wiki/Video_Tutorial/Turning_off_object_selection_glow ) is extremely inconvenient involving changing the SelectionHighlightThickness debug setting and relogging every time you want to turn them on or off. Having a menu item to turn them on or off means that they can be toggled on the fly without even losing your current selection. I'd appreciate any feedback people may have, and if someone could review the patch with a view to committing it to http-texture. Aimee. From robin.cornelius at gmail.com Thu May 14 10:52:24 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 14 May 2009 18:52:24 +0100 Subject: [sldev] Crash reports analysis [http-texture builds] In-Reply-To: <4A0C4953.4050306@lindenlab.com> References: <9E20290B-FB30-423B-A266-EF6ECF480E95@lindenlab.com> <4A0C4953.4050306@lindenlab.com> Message-ID: <4A0C5A58.3040603@gmail.com> Rob Lanphier wrote: > Reviving old discussion..... Copying in directly the two resident openjpeg experts, esp as Callum is not so active in SL now but still very involved in openjpeg >> > Well....this seems like a concerning thing to let just lay around. I've > got a few questions about this: > 1. The SLDev Viewer should be using KDU by default. Is there some > functionality (e.g. the new map) that uses OpenJPEG by default, even if > KDU is available? No, but some of us don't use KDU *at all* because it does not support 64bit and because its not opensource. Is it even automaticly downloaded any more for the build? There were issues where at one point it did not download even on windows. Regardless of KDU, Openjpeg needs supporting, it would reflect badly on LL to not support it and say yes this is opensource, and we have this shiny open source branch, but you have to use this propriety dependency > 2. Is there something in JIRA about this particular issue already? I don't recall such an issue yet. http://jira.secondlife.com/browse/VWR-2342 was the meta for openjpeg but that seems to have a couple missing. > 3. Since this bug isn't fixed in OpenJPEG 1.3, but the release timeline > for OpenJPEG 2.0 doesn't look clear, what would be the odds of > convincing the OpenJPEG team to ship an OpenJPEG 1.3.1. We've got a > strong preference to stick with releases rather than svn snapshots. 2.0 does not look likely soon. The people behind openjpeg are quite busy. Dzontas has got 2.0 working with secondlife but there are remaining issues mainly to do with progressive downloads i believe. May be he can comment further on exactly what is wrong. > 4. If an OpenJPEG 1.3.1 isn't in the cards, it seems like we should suck > it up and patch our OpenJPEG. Right? There was talk of a 1.3.1 and in fact SVN contains some updates that use the opj_calloc instead of the opj_malloc that fixes this specific issue. But again i think the openjpeg guys have just been too busy to push either 2.0 or 1.3.1 forward. Debian has 1.3-5 and the debian git has 1.3-6 which includes the above fix, instead of *yet another* fork maybe you could track the Debian release (which i am maintainer for) and we can try to keep this backporting of fixes sane and uniform across multiple distributions/platforms etc. > 5. Is the currently shipping SLDev Viewer build still on 1.2? I believe so, although Tofu might know better but looks like 1.3 is hitting 1.23 http://jira.secondlife.com/browse/VWR-4041 1.2 was a show stopper for 64bit systems > > Some of these I'll be able to research myself, but I also know there are > many of you who know this off the tops of your respective heads. I would also like to toss in the mix that openjpeg 1.2, 1.3 or even back to 0.97 has issues with encoding alpha and ends up with the entire alpha channel set to 128 v2.0 fixes this issue, but i believe there is no clear backport to 1.3 for this problem currently. 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/20090514/8f3a0c4b/attachment.pgp From baloo at ursamundi.org Thu May 14 13:49:01 2009 From: baloo at ursamundi.org (Paul Johnson) Date: Thu, 14 May 2009 13:49:01 -0700 Subject: [sldev] Overcoming maximum size of IPC messages sent to SecondLife? In-Reply-To: References: Message-ID: Lev Neiman wrote: > Hello. I am running into a problem where SL exits when i attempt to > send it large IPC message because of some buffer overflow. Is it > possible to increase the size of this buffer, and thus increase the size > of IPC message that can be sent to SL? Why not solve this similar to how TCP/IP solves it? Break the data to go via IPC into smaller "packets" and provide some kind of sequencing information to make sure everything arrives in order. -------------- 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/20090514/194923ce/attachment.pgp From dzonatas at gmail.com Thu May 14 15:29:35 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 14 May 2009 15:29:35 -0700 Subject: [sldev] Crash reports analysis [http-texture builds] In-Reply-To: <4A0C5A58.3040603@gmail.com> References: <9E20290B-FB30-423B-A266-EF6ECF480E95@lindenlab.com> <4A0C4953.4050306@lindenlab.com> <4A0C5A58.3040603@gmail.com> Message-ID: <4A0C9B4F.6070006@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090514/c5130d97/attachment.htm From twisted_laws at hotmail.com Thu May 14 16:24:47 2009 From: twisted_laws at hotmail.com (Twisted Laws) Date: Thu, 14 May 2009 19:24:47 -0400 Subject: [sldev] help with debugging on windows vista with vc 2005 In-Reply-To: References: Message-ID: This is related to http://jira.secondlife.com/browse/VWR-13437 Ok, I can attach to the (linden built) secondlife-oss process that is running. Then I run the viewer until it locks up. When I break it in VC, it only will show me disassembly (expected) but will not show the call stack at all. I just pulled down the latest http-texture code from svn and in the process of compiling it in debug mode so hopefully I can find something that way, but: 1. Any ideas/suggestions on debugging the Linden built version on Windows? 2. Did I need to do something other than attach to a process? Thanks for any ideas. _________________________________________________________________ Hotmail? has ever-growing storage! Don?t worry about storage limits. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090514/2fafe843/attachment.htm From schlenk at uni-oldenburg.de Thu May 14 16:42:20 2009 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Fri, 15 May 2009 01:42:20 +0200 Subject: [sldev] help with debugging on windows vista with vc 2005 In-Reply-To: References: Message-ID: Am 15.05.2009 um 01:24 schrieb Twisted Laws: > This is related to http://jira.secondlife.com/browse/VWR-13437 > > Ok, I can attach to the (linden built) secondlife-oss process that > is running. Then I run the viewer until it locks up. When I > break it in VC, it only will show me disassembly (expected) but will > not show the call stack at all. I just pulled down the latest http- > texture code from svn and in the process of compiling it in debug > mode so hopefully I can find something that way, but: > > 1. Any ideas/suggestions on debugging the Linden built version on > Windows? > 2. Did I need to do something other than attach to a process? If the Lindens compiled with the right options and would have set up a symbol server you could step into the code. Not sure if they did. Michael From robla at lindenlab.com Thu May 14 16:55:53 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 14 May 2009 16:55:53 -0700 Subject: [sldev] Crash reports analysis [http-texture builds] In-Reply-To: <4A0C9B4F.6070006@gmail.com> References: <9E20290B-FB30-423B-A266-EF6ECF480E95@lindenlab.com><4A0C 4953.4050306@lindenlab.com> <4A0C5A58.3040603@gmail.com> <4A0C9B4F.6070006@gmail.com> Message-ID: <4A0CAF89.10104@lindenlab.com> This issue was discussed at length in the Open Source Meeting today: https://wiki.secondlife.com/wiki/Open_Source_Meeting/2009-05-14 Issue filed in JIRA: http://jira.secondlife.com/browse/VWR-13511 Rob On 05/14/2009 03:29 PM, Dzonatas Sol wrote: > Robin Cornelius wrote: > >> >>> 3. Since this bug isn't fixed in OpenJPEG 1.3, but the release timeline >>> for OpenJPEG 2.0 doesn't look clear, what would be the odds of >>> convincing the OpenJPEG team to ship an OpenJPEG 1.3.1. We've got a >>> strong preference to stick with releases rather than svn snapshots. >>> >> >> 2.0 does not look likely soon. The people behind openjpeg are quite >> busy. Dzontas has got 2.0 working with secondlife but there are >> remaining issues mainly to do with progressive downloads i believe. May >> be he can comment further on exactly what is wrong. >> > A little research through the OpenJPEG threads reveal that some of the > team were away (Artic). I tried to ping them but one turns up with an > invalid mail address (was a school address). I'm not sure if the main > programmer has received my mail, as even I have had to juggle mail > addresses lately. > > OpenJPEG 2.0 fully works with alpha (yay!), but it does not support > truncated streams. My tests of it installed in the sl-viewer show its > performance is good. It appears like it fails gracefully when it hits > a truncated stream, but I found that to be unstable when a > deallocation could randomly cause a crash. The OpenJPEG standard > expects the decoders to handled truncated streams, so a fix to > allocate/deallocate truncated streams now seems futile, as it would be > better to just fully implement the code to handle truncated streams. > >> I would also like to toss in the mix that openjpeg 1.2, 1.3 or even back >> to 0.97 has issues with encoding alpha and ends up with the entire >> alpha channel set to 128 v2.0 fixes this issue, but i believe there is >> no clear backport to 1.3 for this problem currently. >> >> > > Not impossible to backport, but highly impractical to throw lots of > free time at it to get it done when it would more worthwhile time > spent to get truncated streams to work in 2.0. If Jerome has made > progress on that and just hasn't posted the progress yet, I hate to > step on toes. Best to wait for the pong? > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Thu May 14 17:19:39 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 14 May 2009 17:19:39 -0700 Subject: [sldev] http-texture merge (svn 2259) Message-ID: <4F996DEF-D2F6-4B02-8630-CAB491EB9BB7@lindenlab.com> Hi guys, I did complete the merge of the most recent 1.23 RC code + most recent internal http-texture to projects/2009/http-texture svn rev 2259. Builds went fine and are available here: - Windows : http://secondlife.com/developers/opensource/downloads/2009/http-texture/2259/Second_Life_1-23-2-2259_OSS_Setup.exe - Mac : http://secondlife.com/developers/opensource/downloads/2009/http-texture/2259/SecondLife_1_23_2_2259_OSS.dmg - Linux : http://secondlife.com/developers/opensource/downloads/2009/http-texture/2259/SecondLife-i686-1.23.2.2259.tar.bz2 This should fix most of the bake textures oddities reported previously on 2244. I've still been able to get crashers (on Curl) or freeze on load (stuck in loading textures in the progress bar). Keep testing :) Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090514/b06cdb85/attachment.htm From dzonatas at gmail.com Thu May 14 18:11:46 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 14 May 2009 18:11:46 -0700 Subject: [sldev] UI & Multithreading performance Message-ID: <4A0CC152.8080900@gmail.com> I wanted to share something a bit of a discovery about the UI and multithreading that may interest those that keep performance in mind. First, an image of omvviewer (slviewer on linux) 1.22.11 with the system monitor run. You'll notice at (time interval): T-250: I started omvviewer. Multiple threads fired and begin work. T-200: It starts to calm after startup. I switch window focus to System Monitor. It idles. T-150: I switch focus back to omvviewer window. It begins the thrash one processor only while other processors idle. 100% single processor usage. T-125: I switch focus back to System Monitor. Omvviewer begins to idle again, notice there is mainly one processor active (above 20% util) at a time. T-50 : Very apparent how only one processor is active at a time. http://mono.dzonux.net/file/omvviewer-20090514.png Second image, this next one is of MonoVida Studio, which uses omvviewer as a backend and C#/Gtk#/Glade# for its front-end. All UI events (keys, motions, etc) are through Gtk. There is no SDL being used. Between T-250 and T-0, I switch often between the chat window "Local Chat" and the main view as I conversate and finally the System Monitor to get a snapshot. Notice that there are mainly two processors that are active at a time. Notice also that there is no 100% usage of a single process like in the previous session at T-150. In fact, the idle nanosleep()/timeout (in the render loop) has been completely disabled since Gtk sends events as they happen instead of the need to poll like in SDL. http://mono.dzonux.net/file/monovida-20090514.png Conclusion, Even when GTK events are still being handled within the main loop of the viewer, GTK appears to detect multiprocessors and multithread as it can. This alone was enough that under normal viewer usage (like a meeting) it never hit 100% processor utilization with GTK. I think this conclusion is more than fair since you'll notice in the first picture that the immediate scene to render is mostly blank in comparison to a scene with several avatars. Enjoy... =) P.S. I think I need to program something to limit so many frames per key event for gtk, as a held-down arrow-up key event, which repeats quick, plus a sudden spike in FPS can make me zoom right out of a sim at max velocity. Obviously, this *surprise* was not an issue with polled events. From tayra.dagostino at gmail.com Fri May 15 11:20:04 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Fri, 15 May 2009 20:20:04 +0200 Subject: [sldev] About AUDIO on linux Message-ID: <20090515202004.7b56a339.tayra.dagostino@gmail.com> I've found a little troublew with audio on linux (debian etch) filled: http://jira.secondlife.com/browse/VWR-13514 The libopenal.so.1 bundled in archive with PN had something broken, if i run secondlife viewer audio don't work (see jira ticket), if i delete libopenal.so.1 from viewer chroot /lib/ audio back operational. I dunno why standard libs are bundled, but i think is really better let every linux user use the libraries from him distro repo, this kind of libs are standard in almost all recent distro. Some time ago other libs cause me (and not only me) some trouble: http://jira.secondlife.com/browse/VWR-11931 same kind of problem, libstdc libs broken, since i delete it and let viewer use my system libs viewer back fully operational (and finally i can see youtube videos inworld XD). at least, why so standard libs are bundled? (a little GCC version divfference can cause this kind of headache) From tayra.dagostino at gmail.com Fri May 15 12:10:24 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Fri, 15 May 2009 21:10:24 +0200 Subject: [sldev] About AUDIO on linux In-Reply-To: <20090515202004.7b56a339.tayra.dagostino@gmail.com> References: <20090515202004.7b56a339.tayra.dagostino@gmail.com> Message-ID: <20090515211024.c8d4503e.tayra.dagostino@gmail.com> On Fri, 15 May 2009 20:20:04 +0200 Tayra Dagostino wrote: > I've found a little troublew with audio on linux (debian etch) > filled: http://jira.secondlife.com/browse/VWR-13514 > > The libopenal.so.1 bundled in archive with PN had something broken, if > i run secondlife viewer audio don't work (see jira ticket), if i > delete libopenal.so.1 from viewer chroot /lib/ audio back operational. Second Life 1.23.2 (2259) May 14 2009 16:06:24 (Second Life OSS) [cut] Audio Driver Version: OpenAL, version 1.1 / OpenAL Community / OpenAL Soft: ALSA Software on default work with PN and RC previous current PN, and with OSS version, i think this audio problem is specific of *THIS* PN.... Second Life 1.23.2 (120258) May 13 2009 18:53:50 (Second Life Public Nightly) From jay_reynolds_freeman at mac.com Sat May 16 04:04:26 2009 From: jay_reynolds_freeman at mac.com (Jay Reynolds Freeman) Date: Sat, 16 May 2009 04:04:26 -0700 Subject: [sldev] Mac build for 1.22.11 can't find libfmodwrapper.dylib In-Reply-To: <20090515202004.7b56a339.tayra.dagostino@gmail.com> References: <20090515202004.7b56a339.tayra.dagostino@gmail.com> Message-ID: <50347586-1C9D-4FE8-8DF2-70D5418E0C3D@mac.com> I have been trying to build 1.22.11 on a Mac Pro with XCode 3.1 under MacOS 10.5.7, all pretty much vanilla. All is well all through the XCode build until the link stage, which fails with inability to find libfmodwrapper.dylib in build-darwin-i386/ (whatever, e.g., "Release"). I do have fmod3.75 installed according to the instructions in https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Mac_OS_X%29 Any ideas? -- Jay Reynolds Freeman --------------------- Jay_Reynolds_Freeman at mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) From janai.moses at gmail.com Sat May 16 08:12:00 2009 From: janai.moses at gmail.com (janai.moses at gmail.com) Date: Sat, 16 May 2009 17:12:00 +0200 Subject: [sldev] Member Miss Janai has invited you as a friend on the 3D Virtual World moove online Message-ID: <20090516151202.5C7AF594219@anacondasqueeze.lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090516/12460121/attachment.htm From carlo at alinoe.com Sat May 16 10:40:24 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 16 May 2009 19:40:24 +0200 Subject: [sldev] Another Technical question Message-ID: <20090516174024.GA14420@alinoe.com> I tried to change the code of my viewer in order to create new scripts that are full permission by default. (The reason why I want that is explained below, but not really relevant). I changed in llpanelcontents.cpp, in function LLPanelContents::onClickNewScript, the call LLPermissions perm; perm.init(gAgent.getID(), gAgent.getID(), LLUUID::null, LLUUID::null); perm.initMasks( PERM_ALL, PERM_ALL, PERM_NONE, PERM_NONE, PERM_MOVE | PERM_ITEM_UNRESTRICTED); Where the "PERM_ITEM_UNRESTRICTED" for the last parameter (next owner) was changed from PERM_ITEM_TRANSFER. However... all I get is a script that has ONLY the 'transfer' permission for next owner set :/. I can't seem to figure out why those permissions can't be set here-- or what goes wrong-- or even how to change this function to do whatever to set the permissions to another value. Ie, I looked at what happens if you click on the permission check boxes, and then added to the bottom of LLPanelContents::onClickNewScript: perm.initMasks(PERM_ALL, PERM_ALL, PERM_NONE, PERM_NONE, PERM_ALL); new_item->setPermissions(perm); object->updateInventory(new_item, TASK_INVENTORY_ITEM_KEY, false); but even that doesn't change the permissions of the created script!? Can someone tell me what is going on here? -- Carlo Wood PS The reason I want this is because I share my build objects with someone. We have eachothers build permissions, but still need to shift-copy objects in order to get access to scripts. Hence, all scripts (and everything else) has to be full perm while working on it. The problem is that this is often *forgotten* with as result lost permissions for both. From stickman at gmail.com Sat May 16 11:18:58 2009 From: stickman at gmail.com (Stickman) Date: Sat, 16 May 2009 11:18:58 -0700 Subject: [sldev] Another Technical question In-Reply-To: <20090516174024.GA14420@alinoe.com> References: <20090516174024.GA14420@alinoe.com> Message-ID: On Sat, May 16, 2009 at 10:40 AM, Carlo Wood wrote: > I tried to change the code of my viewer in order to > create new scripts that are full permission by > default. I seem to recall something about a default perm mask on uploaded files being available in 1.23. Was that not the case? -Stickman From melinda at superliminal.com Sat May 16 12:41:51 2009 From: melinda at superliminal.com (Melinda Green) Date: Sat, 16 May 2009 12:41:51 -0700 Subject: [sldev] Another Technical question In-Reply-To: <20090516174024.GA14420@alinoe.com> References: <20090516174024.GA14420@alinoe.com> Message-ID: <4A0F16FF.50308@superliminal.com> The permissions you care capable of setting on existing objects are sometimes different from what you can specify when creating new objects. There are lots of different kinds of objects and lots of different way in which they can be created. E.G. uploads, in-inventory, in-world, in object contents, etc. VWR-8049 is the meta task for rectifying these idiosyncrasies, and VWR-12121 is the sub-task that addresses script creation in particular. The only way to currently do what you're trying to do would be to trigger a callback when your newly created script shows up, which then attempts to set its permissions the way you want. That would be such a horrible hack that it's not worth attempting. Instead, the above tasks are meant to provide the back-end object creation API support such that the approach that you are assuming should work, can actually work. To Stickman who wrote: "I seem to recall something about a default perm mask on uploaded files being available in 1.23. Was that not the case?", That was VWR-8624 which is indeed in 1.23 but which only deals with uploaded content. I hope that helps. -Melinda Carlo Wood wrote: > I tried to change the code of my viewer in order to > create new scripts that are full permission by > default. (The reason why I want that is explained > below, but not really relevant). > > I changed in llpanelcontents.cpp, in function > LLPanelContents::onClickNewScript, the call > > LLPermissions perm; > perm.init(gAgent.getID(), gAgent.getID(), LLUUID::null, LLUUID::null); > perm.initMasks( > PERM_ALL, > PERM_ALL, > PERM_NONE, > PERM_NONE, > PERM_MOVE | PERM_ITEM_UNRESTRICTED); > > > Where the "PERM_ITEM_UNRESTRICTED" for the last parameter > (next owner) was changed from PERM_ITEM_TRANSFER. > > However... all I get is a script that has ONLY > the 'transfer' permission for next owner set :/. > > I can't seem to figure out why those permissions > can't be set here-- or what goes wrong-- or even > how to change this function to do whatever to > set the permissions to another value. > > Ie, I looked at what happens if you click on > the permission check boxes, and then added to > the bottom of LLPanelContents::onClickNewScript: > > perm.initMasks(PERM_ALL, PERM_ALL, PERM_NONE, PERM_NONE, PERM_ALL); > new_item->setPermissions(perm); > object->updateInventory(new_item, TASK_INVENTORY_ITEM_KEY, false); > > but even that doesn't change the permissions of > the created script!? > > Can someone tell me what is going on here? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090516/05e7a21e/attachment.htm From sllists at boroon.dasgupta.ch Sat May 16 14:15:31 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 16 May 2009 23:15:31 +0200 Subject: [sldev] [IDEA][META] janitor and carwash branches Message-ID: <4A0F2CF3.6080608@boroon.dasgupta.ch> Hi all It's already some time ago, that I proposed to manage a hg branch for fast-track integration of trivial-to-review changes. (See https://lists.secondlife.com/pipermail/sldev/2009-May/thread.html#13610) Based on the feedback I got I'd like to change the proposed setup to one with two branches, slviewer-janitor and slviewer-carwash. To both branches, the restrictions named in my original proposal will apply. Additionally, the janitor branch would only include changes (not counting the ones merged over from LL managed branches) that are local (i.e. only touch some few lines of code) and that therefor are easy to merge back upstream. This will probably mostly be typos, but if a recent change in an LL managed branch messes up indentation of some single lines and this can't or won't be fixed in that branch for some reason, it could be fixed in the janitor branch. The carwash branch would be based off the janitor branch and would be the place for the rest of changes fitting the rules of the original proposal. A typical example would be fixing long-ago messed up indentation of a whole file, or even several ones. Automatic car wash plants are usually one way, so don't expect stuff here to be merged back upstream. (It would make merging between the various LL branches difficult, see https://lists.secondlife.com/pipermail/sldev/2009-May/013611.html .) Splitting up a logical change into a lot of single-line commits to get it into janitor instead of carwash wouldn't be accepted, of course, because it would defeat the reason for this separation (and would make review and merging even more troublesome). Because changes in the janitor branch might never make it into any other branches (or at least not until we find a more intelligent---maybe even programming language aware---merge tool) , I won't encourage anyone to create changes for it. But if someone creates them anyway, they're welcome to send me pull requests :-) Again, please let me know what you think. Especially: * Would this be useful? * Is it doable? * (mainly @LL) Would you pull from slviewer-janitor? cheers Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090516/442bc9a9/attachment.htm From carlo at alinoe.com Sat May 16 16:43:22 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 17 May 2009 01:43:22 +0200 Subject: [sldev] [IDEA][META] janitor and carwash branches In-Reply-To: <4A0F2CF3.6080608@boroon.dasgupta.ch> References: <4A0F2CF3.6080608@boroon.dasgupta.ch> Message-ID: <20090516234322.GA32735@alinoe.com> On Sat, May 16, 2009 at 11:15:31PM +0200, Boroondas Gupte wrote: > for the rest of changes fitting the rules of the original proposal. A typical > example would be fixing long-ago messed up indentation of a whole file, or even > several ones. Automatic car wash plants are usually one way, so don't expect > > ? Would this be useful? > ? Is it doable? Seems to me that indentation of files can never work unless you use merge tools that ignore changes in white space. But well.. not worth more words.. it would be a maintenance nightmare with the number of branches and repositories we have. It's unfortunate, but indentation cannot be changed. > ? (mainly @LL) Would you pull from slviewer-janitor? It would be nice to have write access to some repository that I could do a quick commit to. Right now I have to create a new JIRA, and create a new topgit branch (for the omvviewer that I have write access for) etc etc, which is so much work that I often consider it not worth it (Ie, typos in comments -- or a C-style cast that I ran into which makes the code less robust (should have been a static_cast)). -- Carlo Wood From feilen1000 at gmail.com Sat May 16 17:40:05 2009 From: feilen1000 at gmail.com (Feilen) Date: Sat, 16 May 2009 19:40:05 -0500 Subject: [sldev] Hide geometry in Sculpted-prims Message-ID: <4A0F5CE5.2090307@gmail.com> For all the misgivings about sculpted prims, the greatest number are about how all objects have to have perfect UV-mapping, making it nearly impossible in most cases to export existing objects into the format. What I propose would fix this entirely: Simply make the renderer not render geometry connecting to the origin, aka 0,0,0 or black color on the sculpt map. This would solve the problem simply because by default exporters paint unused geometry black, which ruins some potential models, but would make it very easy to simply not draw triangles with a point at 0,0,0 and greatly improve sculpty submission quality. From dmahalko at gmail.com Sat May 16 20:57:31 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat, 16 May 2009 22:57:31 -0500 Subject: [sldev] Hide geometry in Sculpted-prims In-Reply-To: <4A0F5CE5.2090307@gmail.com> References: <4A0F5CE5.2090307@gmail.com> Message-ID: So you want to put a seam into the perfectly uniform mesh? I don't think what you want can be done because it may break some existing sculpts that do just happen to use the coordinate you mention. (We can't know that without searching the assets for all sculpts ever made, but it is possible.) Also using 0,0,0 for seam generation takes out eight triangles around the point, which burns two rows/columns of precious triangles. +----+----+----+----+ | .'| .'| .'| ,'| |.' |.' |.' |.' | +----+----+----+----+ | .'| | ,'| |.' | |.' | +----+ O +----+ point to 0,0,0 | .'| | .'| kills eight tris |.' | |.' | +----+----+----+----+ | .'| .'| .'| ,'| |.' |.' |.' |.' | +----+----+----+----+ Might be workable to kill just six tris, though still lots to be killed per jump to 0,0,0. +----+----+----+----+ | .'| .'| .'| ,'| |.' |.' |.' |.' | +----+----+----+----+ | .'| .' | ,'| |.' |.' |.' | +----+ O +----+ point to 0,0,0 | .'| .'| .'| kills six tris |.' | .' |.' | +----+----+----+----+ | .'| .'| .'| ,'| |.' |.' |.' |.' | +----+----+----+----+ I am in favor of using the unused alpha channel for seaming information. This allows just two tris to be killed if the alpha for a UV map point is set to zero. Alpha map: (100% is totally transparent so no need to draw) 0% 0% 0% 0% 0% 100% 0% 0% 0% 100% 100% 0% 0% 0% 0% 0% Tris map: +----+----+----+----+ | .'| .'| .'| .'| |.' |.' |.' |.' | +----+----+----+----+ | .'|KILL| .'| .'| |.' | |.' |.' | +----+ +----+----+ | .'|KILL KILL| .'| |.' | |.' | +----+----+----+----+ | .'| .'| .'| .'| |.' |.' |.' |.' | +----+----+----+----+ - Dale Mahalko / Scalar Tardis (ASCII artist) (If this email looks like a jumbled mess, use a monospace font to render ASCII art correctly.) On Sat, May 16, 2009 at 7:40 PM, Feilen wrote: > For all the misgivings about sculpted prims, the greatest number are > about how all objects have to have perfect UV-mapping, making it nearly > impossible in most cases to export existing objects into the format. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090516/b22b284d/attachment.htm From dmahalko at gmail.com Sat May 16 21:05:50 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat, 16 May 2009 23:05:50 -0500 Subject: [sldev] Hide geometry in Sculpted-prims In-Reply-To: References: <4A0F5CE5.2090307@gmail.com> Message-ID: Woohoo, GMail screwed up the monospacing AFTER it was sent, and the gmail plain text mode doesn't match the formatted monospace in the regular view. Sorry if that last email is incomprehensible. Attempted fix, though who knows what it'll actually do when I hit send. - Dale On Sat, May 16, 2009 at 10:57 PM, Dale Mahalko wrote: > > So you want to put a seam into the perfectly uniform mesh? I don't think what you want can be done because it may break some existing sculpts that do just happen to use the coordinate you mention. (We can't know that without searching the assets for all sculpts ever made, but it is possible.) > > Also using 0,0,0 for seam generation takes out eight triangles around the point, which burns two rows/columns of precious triangles. > > +----+----+----+----+ > | .'| .'| .'| ,'| > |.' |.' |.' |.' | > +----+----+----+----+ > | .'| | ,'| > |.' | |.' | > +----+ O +----+ point to 0,0,0 > | .'| | .'| kills eight tris > |.' | |.' | > +----+----+----+----+ > | .'| .'| .'| ,'| > |.' |.' |.' |.' | > +----+----+----+----+ > > Might be workable to kill just six tris, though still lots to be killed per jump to 0,0,0. > > +----+----+----+----+ > | .'| .'| .'| ,'| > |.' |.' |.' |.' | > +----+----+----+----+ > | .'| .' | ,'| > |.' |.' |.' | > +----+ O +----+ point to 0,0,0 > | .'| .'| .'| kills six tris > |.' | .' |.' | > +----+----+----+----+ > | .'| .'| .'| ,'| > |.' |.' |.' |.' | > +----+----+----+----+ > > > I am in favor of using the unused alpha channel for seaming information. This allows just two tris to be killed if the alpha for a UV map point is set to zero. > > Alpha map: (100% is totally transparent so no need to draw) > 0% 0% 0% 0% > 0% 100% 0% 0% > 0% 100% 100% 0% > 0% 0% 0% 0% > > Tris map: > +----+----+----+----+ > | .'| .'| .'| .'| > |.' |.' |.' |.' | > +----+----+----+----+ > | .'|KILL| .'| .'| > |.' | |.' |.' | > +----+ +----+----+ > | .'|KILL KILL| .'| > |.' | |.' | > +----+----+----+----+ > | .'| .'| .'| .'| > |.' |.' |.' |.' | > +----+----+----+----+ > > - Dale Mahalko / Scalar Tardis (ASCII artist) > > (If this email looks like a jumbled mess, use a monospace font to render ASCII art correctly.) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090516/28d5b226/attachment-0001.htm From feilen1000 at gmail.com Sat May 16 22:54:31 2009 From: feilen1000 at gmail.com (Feilen) Date: Sun, 17 May 2009 00:54:31 -0500 Subject: [sldev] Hide geometry in Sculpted-prims In-Reply-To: References: <4A0F5CE5.2090307@gmail.com> Message-ID: <4A0FA697.2050706@gmail.com> That's actually a lot better of an idea, and it would be simple to implement: just use any basic image editor to implement the alpha and remove all of the black space the 3d modeler creates. If this was implemented it would be likely that all plugins/modelers supporting would also change to generate alpha instead of blackspace. Dale Mahalko wrote: > Woohoo, GMail screwed up the monospacing AFTER it was sent, and the > gmail plain text mode doesn't match the formatted monospace in the > regular view. Sorry if that last email is incomprehensible. > > Attempted fix, though who knows what it'll actually do when I hit send. > > - Dale > > > On Sat, May 16, 2009 at 10:57 PM, Dale Mahalko > wrote: > > > > So you want to put a seam into the perfectly uniform mesh? I don't > think what you want can be done because it may break some existing > sculpts that do just happen to use the coordinate you mention. (We > can't know that without searching the assets for all sculpts ever > made, but it is possible.) > > > > Also using 0,0,0 for seam generation takes out eight triangles > around the point, which burns two rows/columns of precious triangles. > > > > +----+----+----+----+ > > | .'| .'| .'| ,'| > > |.' |.' |.' |.' | > > +----+----+----+----+ > > | .'| | ,'| > > |.' | |.' | > > +----+ O +----+ point to 0,0,0 > > | .'| | .'| kills eight tris > > |.' | |.' | > > +----+----+----+----+ > > | .'| .'| .'| ,'| > > |.' |.' |.' |.' | > > +----+----+----+----+ > > > > Might be workable to kill just six tris, though still lots to be > killed per jump to 0,0,0. > > > > +----+----+----+----+ > > | .'| .'| .'| ,'| > > |.' |.' |.' |.' | > > +----+----+----+----+ > > | .'| .' | ,'| > > |.' |.' |.' | > > +----+ O +----+ point to 0,0,0 > > | .'| .'| .'| kills six tris > > |.' | .' |.' | > > +----+----+----+----+ > > | .'| .'| .'| ,'| > > |.' |.' |.' |.' | > > +----+----+----+----+ > > > > > > I am in favor of using the unused alpha channel for seaming > information. This allows just two tris to be killed if the alpha for a > UV map point is set to zero. > > > > Alpha map: (100% is totally transparent so no need to draw) > > 0% 0% 0% 0% > > 0% 100% 0% 0% > > 0% 100% 100% 0% > > 0% 0% 0% 0% > > > > Tris map: > > +----+----+----+----+ > > | .'| .'| .'| .'| > > |.' |.' |.' |.' | > > +----+----+----+----+ > > | .'|KILL| .'| .'| > > |.' | |.' |.' | > > +----+ +----+----+ > > | .'|KILL KILL| .'| > > |.' | |.' | > > +----+----+----+----+ > > | .'| .'| .'| .'| > > |.' |.' |.' |.' | > > +----+----+----+----+ > > > > - Dale Mahalko / Scalar Tardis (ASCII artist) > > > > (If this email looks like a jumbled mess, use a monospace font to > render ASCII art correctly.) > From jay_reynolds_freeman at mac.com Sun May 17 02:46:56 2009 From: jay_reynolds_freeman at mac.com (Jay Reynolds Freeman) Date: Sun, 17 May 2009 02:46:56 -0700 Subject: [sldev] Mac build for 1.22.11 can't find libfmodwrapper.dylib, more information ... In-Reply-To: <50347586-1C9D-4FE8-8DF2-70D5418E0C3D@mac.com> References: <20090515202004.7b56a339.tayra.dagostino@gmail.com> <50347586-1C9D-4FE8-8DF2-70D5418E0C3D@mac.com> Message-ID: <6482FCEE-5E3A-4601-8791-3D17BCEA0AE7@mac.com> Reposting with slightly more information: On May 16, 2009, at 4:04 AM, Jay Reynolds Freeman (that's me) wrote: > I have been trying to build 1.22.11 on a Mac Pro with XCode 3.1 > under MacOS 10.5.7, all pretty much vanilla. All is well all > through the XCode build until the link stage, which fails with > inability to find libfmodwrapper.dylib in build-darwin-i386/ > (whatever, e.g., "Release"). I do have fmod3.75 installed > according to the instructions in > > https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Mac_OS_X%29 > > Any ideas? I should note that I found reported issue VWR-11453, and made the one- line change in newview/CMakeLists.txt that was suggested therein. No fix, same error message. I see a lot of other comments about what may be related errors when I keyword-search the issues for libfmodwrapper, but I am not sure what to try next. The additional information is, that when I look in the XCode project file (SecondLife.xcodeproj) that CMake has generated for this project, I find that it contains a "Resources" folder which is completely empty. There is some indication that one of the CMake files, together with a file called viewer_manifest.py, is supposed to load or create some resources, but I am not enough of a CMake or Python expert to figure out what is going wrong. I cannot find any reference to libfmodwrapper.dylib anywhere in the XCode project file. The fact that the "Resources" folder is empty, seems ominous. For comparison, in 1.20.17, which is the last build I have worked with extensively, libfmodwrapper.dylib is listed as a Target in the XCode project file, and is evidently getting built as required therein. ??? -- Jay Reynolds Freeman --------------------- Jay_Reynolds_Freeman at mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) From nexiim at googlemail.com Sun May 17 05:50:48 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Sun, 17 May 2009 13:50:48 +0100 Subject: [sldev] Hide geometry in Sculpted-prims In-Reply-To: <4A0FA697.2050706@gmail.com> References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> Message-ID: <824c8ab70905170550r6356a52en39e5d91fc6dd39b2@mail.gmail.com> The email actually looks perfectly fine to me Dale. Hm, alpha channel of sculpties, well the problem is, there are a lot of ideas going around about what to do with the alpha channel, Qarl wanted to do something else with it, currently its majorly used by creators to put in their signature embedded into the sculpty via this channel. On Sun, May 17, 2009 at 6:54 AM, Feilen wrote: > That's actually a lot better of an idea, and it would be simple to > implement: just use any basic image editor to implement the alpha and > remove all of the black space the 3d modeler creates. If this was > implemented it would be likely that all plugins/modelers supporting > would also change to generate alpha instead of blackspace. > > > Dale Mahalko wrote: > > Woohoo, GMail screwed up the monospacing AFTER it was sent, and the > > gmail plain text mode doesn't match the formatted monospace in the > > regular view. Sorry if that last email is incomprehensible. > > > > Attempted fix, though who knows what it'll actually do when I hit send. > > > > - Dale > > > > > > On Sat, May 16, 2009 at 10:57 PM, Dale Mahalko > > wrote: > > > > > > So you want to put a seam into the perfectly uniform mesh? I don't > > think what you want can be done because it may break some existing > > sculpts that do just happen to use the coordinate you mention. (We > > can't know that without searching the assets for all sculpts ever > > made, but it is possible.) > > > > > > Also using 0,0,0 for seam generation takes out eight triangles > > around the point, which burns two rows/columns of precious triangles. > > > > > > +----+----+----+----+ > > > | .'| .'| .'| ,'| > > > |.' |.' |.' |.' | > > > +----+----+----+----+ > > > | .'| | ,'| > > > |.' | |.' | > > > +----+ O +----+ point to 0,0,0 > > > | .'| | .'| kills eight tris > > > |.' | |.' | > > > +----+----+----+----+ > > > | .'| .'| .'| ,'| > > > |.' |.' |.' |.' | > > > +----+----+----+----+ > > > > > > Might be workable to kill just six tris, though still lots to be > > killed per jump to 0,0,0. > > > > > > +----+----+----+----+ > > > | .'| .'| .'| ,'| > > > |.' |.' |.' |.' | > > > +----+----+----+----+ > > > | .'| .' | ,'| > > > |.' |.' |.' | > > > +----+ O +----+ point to 0,0,0 > > > | .'| .'| .'| kills six tris > > > |.' | .' |.' | > > > +----+----+----+----+ > > > | .'| .'| .'| ,'| > > > |.' |.' |.' |.' | > > > +----+----+----+----+ > > > > > > > > > I am in favor of using the unused alpha channel for seaming > > information. This allows just two tris to be killed if the alpha for a > > UV map point is set to zero. > > > > > > Alpha map: (100% is totally transparent so no need to draw) > > > 0% 0% 0% 0% > > > 0% 100% 0% 0% > > > 0% 100% 100% 0% > > > 0% 0% 0% 0% > > > > > > Tris map: > > > +----+----+----+----+ > > > | .'| .'| .'| .'| > > > |.' |.' |.' |.' | > > > +----+----+----+----+ > > > | .'|KILL| .'| .'| > > > |.' | |.' |.' | > > > +----+ +----+----+ > > > | .'|KILL KILL| .'| > > > |.' | |.' | > > > +----+----+----+----+ > > > | .'| .'| .'| .'| > > > |.' |.' |.' |.' | > > > +----+----+----+----+ > > > > > > - Dale Mahalko / Scalar Tardis (ASCII artist) > > > > > > (If this email looks like a jumbled mess, use a monospace font to > > render ASCII art correctly.) > > > > _______________________________________________ > 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/20090517/f68635dc/attachment.htm From nexiim at googlemail.com Sun May 17 09:28:32 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Sun, 17 May 2009 17:28:32 +0100 Subject: [sldev] Member Miss Janai has invited you as a friend on the 3D Virtual World moove online In-Reply-To: <20090516151202.5C7AF594219@anacondasqueeze.lindenlab.com> References: <20090516151202.5C7AF594219@anacondasqueeze.lindenlab.com> Message-ID: <824c8ab70905170928ic97895dt87ba0620be6864ae@mail.gmail.com> That thing just screams cybersex from the suggestive pictures. I wouldn't touch it with a 10 feet pole. Not to mention, wouldn't trust any application that forcefully spammed mailing lists... On Sat, May 16, 2009 at 4:12 PM, wrote: > *moove online* - virtual 3D World - I ? [image: moove online] > ------------------------------ > > Hi, > > I am inviting you to join me at moove online! > > I have my own 3D house - completely private. Just visit me and we can do > everything with our most realistic 3D avatars :-) > > Warmest greetings from > Miss Janai [image: > Surfer] > ------------------------------ > >> Accept invitation from Miss Janai!- > *moove online membership and houses are free.* > > If clicking the link above does not work, please copy and paste the link > below into the address bar of your browser: > > You are receiving this e-mail because *janai.moses at gmail.com*aka > *Miss Janai * who knows > you sent you an invitation to join them on moove online. moove will not use > or retain your e-mail address for any other purpose as a result of this > referral. If you want to prevent any future invitation e-mail from any moove > member, please click the following link. Thank you! > > I do not want to receive invitations to moove online. > ------------------------------ > moove.com - moove online - About Us > > _______________________________________________ > 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/20090517/34e109c4/attachment.htm From secret.argent at gmail.com Sun May 17 10:01:07 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 17 May 2009 12:01:07 -0500 Subject: [sldev] Hide geometry in Sculpted-prims In-Reply-To: <4A0FA697.2050706@gmail.com> References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> Message-ID: On 2009-05-17, at 00:54, Feilen wrote: > That's actually a lot better of an idea, and it would be simple to > implement: just use any basic image editor to implement the alpha and > remove all of the black space the 3d modeler creates. If this was > implemented it would be likely that all plugins/modelers supporting > would also change to generate alpha instead of blackspace. The problem is that Alpha is planned to be used for flexibility in sculpties, and there are already experimental version of the Open Source viewer testing this. It would probably be better to add a flag (like the flag proposed for indicating flexible sculpties) indicating that <0,0,0> was not part of the geometry. From dahliatrimble at gmail.com Sun May 17 10:05:29 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sun, 17 May 2009 10:05:29 -0700 Subject: [sldev] Hide geometry in Sculpted-prims In-Reply-To: References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> Message-ID: I've also seen a lot of designers use the alpha channel to mask the entire bitmap so it doesn't show in the editor and can't be grabbed with a screen capture On Sun, May 17, 2009 at 10:01 AM, Argent Stonecutter < secret.argent at gmail.com> wrote: > On 2009-05-17, at 00:54, Feilen wrote: > > That's actually a lot better of an idea, and it would be simple to > > implement: just use any basic image editor to implement the alpha and > > remove all of the black space the 3d modeler creates. If this was > > implemented it would be likely that all plugins/modelers supporting > > would also change to generate alpha instead of blackspace. > > The problem is that Alpha is planned to be used for flexibility in > sculpties, and there are already experimental version of the Open > Source viewer testing this. > > It would probably be better to add a flag (like the flag proposed for > indicating flexible sculpties) indicating that <0,0,0> was not part of > the geometry. > > _______________________________________________ > 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/20090517/cfcdd7ba/attachment-0001.htm From robla at lindenlab.com Sun May 17 11:29:28 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Sun, 17 May 2009 11:29:28 -0700 Subject: [sldev] SLDev Viewer crash+usage stats Message-ID: <4A105788.706@lindenlab.com> Hi folks, Here's a little bit of data about crashes and usage for the SLDev Viewer for the past week: Second Life OSS 1.23.2.2259: 2009-05-16: 3 crashes 2009-05-15: 2 crashes 2009-05-14: 5 crashes, 4.47 hours, 15 sessions, 6 users Second Life OSS 1.23.0.2244: 2009-05-15: 1 crashes 2009-05-14: 1 crashes, 13.97 hours, 17 sessions, 9 users 2009-05-13: 4 crashes, 15.10 hours, 27 sessions, 15 users 2009-05-12: 6 crashes, 24.75 hours, 40 sessions, 15 users 2009-05-11: 0 crashes, 0.22 hours, 3 sessions, 1 users Second Life OSS 1.23.0.2235: 2009-05-11: 0 crashes, 4.02 hours, 9 sessions, 3 users Second Life OSS 1.23.0.2232: 2009-05-14: 2 crashes, 0.77 hours, 2 sessions, 1 users 2009-05-11: 4 crashes, 0.67 hours, 9 sessions, 2 users Second Life OSS 1.23.0.2220: 2009-05-12: 0 crashes, 0.10 hours, 2 sessions, 1 users Second Life OSS 1.23.0.2114: 2009-05-12: 0 crashes, 0.00 hours, 1 sessions, 1 users We'll likely want to automate the sending of this information every night. Not sure if this should just go straight to sldev or sldev-commits or a new list. Your thoughts appreciated here: http://jira.secondlife.com/browse/VWR-13573 Rob From malachi at tamzap.com Sun May 17 11:32:25 2009 From: malachi at tamzap.com (malachi at tamzap.com) Date: Sun, 17 May 2009 14:32:25 -0400 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: References: <4A0F5CE5.2090307@gmail.com><4A0FA697.2050706@gmail.com> Message-ID: i spend time in regions where weapons play is held and even just in places where gadgets and scanners are used or sold and the resources used by these devices are amazing. even to the point that sometimes these devices cause the region to hiccup or even crash because of the amount of resources used to send all the probes around the region to collect the keys of all the agents in the region. in most cases creators are using multiple probes sometimes upwards in the amount of 100 probes to scan the region for agents. this all being done to increase the scan range of llSensor from 96m to ~. but what they dont see is the effect on the region itself having to run all these scripts. yes a single avatar running a probing system wont effect the region. but slam 50-60 people all using these scanners and the sim runs like a commodore 64. we already know that the simulator holds the data of who is there and when. and given the recent addition to the lsl language for llGetRegionAgentCount() wouldnt it be just as easy to add some function to return the agent keys that are present on the region. this would eliminate the use of all probe scanners. and ultimately increase the performance of the region. im not a c programmer im still looking at all this code and trying to find ways to better what i see. im still learning. but i am 100% sure that someone in this list is capable of finding a way to add a function that would return this list. i havent tried testing a lot of people using scanners this way on a mainland region but i am almost certain id crash before the probes were fully deployed lol. if this is possible could someone explain it more in detail about how to get started on doing this. a patch perhaps? thank you all for your time. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090517/c6d58094/attachment.htm From sllists at boroon.dasgupta.ch Sun May 17 13:13:55 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 17 May 2009 22:13:55 +0200 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: References: <4A0F5CE5.2090307@gmail.com><4A0FA697.2050706@gmail.com> Message-ID: <4A107003.1030808@boroon.dasgupta.ch> malachi at tamzap.com schrieb: > we already know that the simulator holds the data of who is there and > when. and given the recent addition to the lsl language for > llGetRegionAgentCount() wouldnt it be just as easy to add some > function to return the agent keys that are present on the region. this > would eliminate the use of all probe scanners. and ultimately increase > the performance of the region. > > [...] > > if this is possible could someone explain it more in detail about how > to get started on doing this. a patch perhaps? As most of the server side of Second Life is still closed source, only Linden Lab could implement such an sim-to-LSL interface. http://jira.secondlife.com/browse/SVC-58 seems to be what you request, so you might want to vote for it. If the data should actually be displayed to the end user and a script is just used to fetch it (e.g. for display on a HUD), that could very well be replaced by new functionality of the viewer, which is aware of other avatars on the same sim even outside of draw distance (the data is needed for the mini-map anyway). To see what's possible there, have a look at Dale Glass' modifications to the viewer: http://wiki.secondlife.com/wiki/Alternate_viewers#Dale_Glass_Edition Of course, if the data for some reason has to be processed in a sim-side script and LL doesn't implement SVC-58, you could still get a modified viewer (or a bot) to transfer it back inworld via hidden chat channels. http://wiki.secondlife.com/wiki/Alternate_viewers#Marine_Edition uses this technique. cheers Boroondas From open at autistici.org Sun May 17 15:10:22 2009 From: open at autistici.org (Opensource Obscure) Date: Sun, 17 May 2009 22:10:22 +0000 Subject: [sldev] Finding the latest build (Re: Experience so far with 2244) In-Reply-To: <4A0B344B.9050804@lindenlab.com> References: <4A0A57A9.8090300@lindenlab.com> <4A0B344B.9050804@lindenlab.com> Message-ID: <9d77ef3f1b4555e52e64c8888220e215@localhost> On Wed, 13 May 2009 13:57:47 -0700, Rob Lanphier wrote: > 3. Generally, there's someone that pounces on the build right away. If > they have a reasonably good experience with it, they'll update the > latest build page here: > https://wiki.secondlife.com/wiki/Open_Source_Portal > > If you'd like to update that page, the place to do the updating is > actually here: > https://wiki.secondlife.com/wiki/Template:Open_Source_Portal/Featured > > Please only do this after you've successfully run the build yourself and > verified that it at least doesn't crash on startup on your favorite > platform. To date, only Merov and I have updated this, but I don't > think others should be shy about doing so. I just updated the Open Source Portal page with links to the 1.23.2-2259 build installers. I had to update this template: https://wiki.secondlife.com/wiki/Template:Ossbuild-installers because it's itself referenced by Template:Open_Source_Portal/Featured I added a note to Template:Ossbuild-installers to reflect the fact that the template must be updated at each new release (1.23.0, 1.23.1, 1.23.2...). Hope this was correct. ciao Opensource Obscure From dmahalko at gmail.com Sun May 17 15:53:01 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Sun, 17 May 2009 17:53:01 -0500 Subject: [sldev] Hide geometry in Sculpted-prims In-Reply-To: References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> Message-ID: Ahem, so the problem is that people are limited to just four two-dimensional arrays of R G B and Alpha. It appears that what are needed are more 2D arrays but the image interface is already maxed out with the current implementation, and Alpha is being used by people for undefined purposes because it currently has NO defined purpose. Expansion is needed for more 2D arrays and more data storage, but this is going to break the ever so simple and clever concept of sculpts as RGB maps. Probably because it is too simple and clever to really be practical in the first place. What image formats allow additional hidden 2D arrays not used for image generation? So we need a Beta channel, on up to Zeta, or whatever. Maybe it's time to drop the "image" concept and go with a new "variable size 1D array of 2D arrays" data format, with each 2D array compressed with lossy wavelet compression where practical. I fully realize I am trodding on Phillip Rosedale's baby here so I don't expect any sort of positive reception of this discusion. :-) - Dale On Sun, May 17, 2009 at 12:05 PM, Dahlia Trimble wrote: > I've also seen a lot of designers use the alpha channel to mask the entire > bitmap so it doesn't show in the editor and can't be grabbed with a screen > capture > > > On Sun, May 17, 2009 at 10:01 AM, Argent Stonecutter < > secret.argent at gmail.com> wrote: > >> On 2009-05-17, at 00:54, Feilen wrote: >> > That's actually a lot better of an idea, and it would be simple to >> > implement: just use any basic image editor to implement the alpha and >> > remove all of the black space the 3d modeler creates. If this was >> > implemented it would be likely that all plugins/modelers supporting >> > would also change to generate alpha instead of blackspace. >> >> The problem is that Alpha is planned to be used for flexibility in >> sculpties, and there are already experimental version of the Open >> Source viewer testing this. >> >> It would probably be better to add a flag (like the flag proposed for >> indicating flexible sculpties) indicating that <0,0,0> was not part of >> the geometry. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090517/ac91fd19/attachment.htm From tigrospottystripes at gmail.com Sun May 17 16:22:33 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 17 May 2009 20:22:33 -0300 Subject: [sldev] Hide geometry in Sculpted-prims In-Reply-To: References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> Message-ID: <4A109C39.2010807@Gmail.com> how about doing it similarlly to how frame based texture animation works, but having aditional data on the frames after the first, and using the first frame's RGB for sculpty, and the rest, including the alpha of the first frame, for additional data? Dale Mahalko escreveu: > Ahem, so the problem is that people are limited to just four > two-dimensional arrays of R G B and Alpha. It appears that what are > needed are more 2D arrays but the image interface is already maxed out > with the current implementation, and Alpha is being used by people for > undefined purposes because it currently has NO defined purpose. > > Expansion is needed for more 2D arrays and more data storage, but this > is going to break the ever so simple and clever concept of sculpts as > RGB maps. Probably because it is too simple and clever to really be > practical in the first place. > > What image formats allow additional hidden 2D arrays not used for > image generation? So we need a Beta channel, on up to Zeta, or > whatever. Maybe it's time to drop the "image" concept and go with a > new "variable size 1D array of 2D arrays" data format, with each 2D > array compressed with lossy wavelet compression where practical. > > I fully realize I am trodding on Phillip Rosedale's baby here so I > don't expect any sort of positive reception of this discusion. :-) > > - Dale > > From dahliatrimble at gmail.com Sun May 17 16:39:06 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sun, 17 May 2009 16:39:06 -0700 Subject: [sldev] Hide geometry in Sculpted-prims In-Reply-To: <4A109C39.2010807@Gmail.com> References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> <4A109C39.2010807@Gmail.com> Message-ID: How about just putting the text of a .obj file into a notecard and using that? It would be compatible with the current asset system. On Sun, May 17, 2009 at 4:22 PM, Tigro Spottystripes < tigrospottystripes at gmail.com> wrote: > how about doing it similarlly to how frame based texture animation > works, but having aditional data on the frames after the first, and > using the first frame's RGB for sculpty, and the rest, including the > alpha of the first frame, for additional data? > > Dale Mahalko escreveu: > > Ahem, so the problem is that people are limited to just four > > two-dimensional arrays of R G B and Alpha. It appears that what are > > needed are more 2D arrays but the image interface is already maxed out > > with the current implementation, and Alpha is being used by people for > > undefined purposes because it currently has NO defined purpose. > > > > Expansion is needed for more 2D arrays and more data storage, but this > > is going to break the ever so simple and clever concept of sculpts as > > RGB maps. Probably because it is too simple and clever to really be > > practical in the first place. > > > > What image formats allow additional hidden 2D arrays not used for > > image generation? So we need a Beta channel, on up to Zeta, or > > whatever. Maybe it's time to drop the "image" concept and go with a > > new "variable size 1D array of 2D arrays" data format, with each 2D > > array compressed with lossy wavelet compression where practical. > > > > I fully realize I am trodding on Phillip Rosedale's baby here so I > > don't expect any sort of positive reception of this discusion. :-) > > > > - Dale > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090517/9c54e3ec/attachment.htm From dmahalko at gmail.com Sun May 17 16:56:48 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Sun, 17 May 2009 18:56:48 -0500 Subject: [sldev] Extensible Asset Data Format (Re: Hide geometry) Message-ID: Dahlia, Actual mesh file format support, through an extensible asset storage interface, using notecards for extended support of new datatypes not officially approved by LL? What a concept. Actually I've been thinking about an extensible asset storage method for a while. This would allow people to develop new client features that go way above and beyond what asset types LL directly supports, to splice in whatever 3D or other object support they want. NURBS, whatever. Just as long as notecards can handle binary data rather than plain text -- or use something like yEnc on usenet for putting raw binary into notecards. Just segment the data across chains of notecards, as in actual Usenet postings. Do we next throw in PAR encoding for when all the notecards don't load? ;-) Heck, don't even need LL approval to do this, as long as the new exentisible asset storage is compatible with the existing notecard data type. (I can hear a dozen Lindens going.. whoah... whoah... slow down..) - Dale Mahalko / Scalar Tardis On Sun, May 17, 2009 at 6:39 PM, Dahlia Trimble wrote: > How about just putting the text of a .obj file into a notecard and using > that? It would be compatible with the current asset system. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090517/94a56d48/attachment.htm From tigrospottystripes at gmail.com Sun May 17 17:03:35 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 17 May 2009 21:03:35 -0300 Subject: [sldev] Extensible Asset Data Format (Re: Hide geometry) In-Reply-To: References: Message-ID: <4A10A5D7.1080203@Gmail.com> a while back I suggested a friend of mine that plays with the client code (might have been the guy that made flexy sculpties for the first time, my memory isn't quite clear about that) to modify the client to read shader programs from notecards in a prim and use the specified shader on the prim, he told me it was way too complicated to find the notecards on every prim on screen and associate them with the prim they are in, not to mention actually implementing such a shader system Dale Mahalko escreveu: > Dahlia, > > Actual mesh file format support, through an extensible asset storage > interface, using notecards for extended support of new datatypes not > officially approved by LL? What a concept. > > Actually I've been thinking about an extensible asset storage method > for a while. This would allow people to develop new client features > that go way above and beyond what asset types LL directly supports, to > splice in whatever 3D or other object support they want. NURBS, whatever. > > Just as long as notecards can handle binary data rather than plain > text -- or use something like yEnc on usenet for putting raw binary > into notecards. Just segment the data across chains of notecards, as > in actual Usenet postings. Do we next throw in PAR encoding for when > all the notecards don't load? ;-) > > Heck, don't even need LL approval to do this, as long as the new > exentisible asset storage is compatible with the existing notecard > data type. (I can hear a dozen Lindens going.. whoah... whoah... slow > down..) > - Dale Mahalko / Scalar Tardis > > > On Sun, May 17, 2009 at 6:39 PM, Dahlia Trimble > > wrote: > > How about just putting the text of a .obj file into a notecard and > using that? It would be compatible with the current asset system. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Sun May 17 17:23:07 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sun, 17 May 2009 17:23:07 -0700 Subject: [sldev] Extensible Asset Data Format (Re: Hide geometry) In-Reply-To: <4A10A5D7.1080203@Gmail.com> References: <4A10A5D7.1080203@Gmail.com> Message-ID: I don't believe that notecards are automatically delivered when a prim description is sent, it would have to be requested just like any other asset would be. Using a notecard may require multiple steps to retrieve the entire text of the .obj file, but the viewer must be capable of asking for the text of a notecard and receiving it already, or it would not be able to display them at all. There may be other alternatives. Upon entering a region, a special viewer could announce some message on some high numbered chat channel, and a script in a prim could respond with a specially formatted ownersay message that says something like: "*special message* if you're capable, please download a mesh description from http://mymeshstore.com/uuid.obj and display it instead of this prim". Normal viewers would not be likely to see the message as they would not normally be sending instructions out on that chat channel, and the viewer that could use the message could parse it, see that it was a special message, and download and display the mesh rather than showing the user the message. I still think the notecard can work. OBJ files are ascii text so should be compatible with a notecard as long as it can all fit. OBJ files can describe many different geometries quite effectively, and the size of the files can be minimized by being prudent about not using excessive precision in the floating point numbers contained in the file. If there were some geometry specified in the file that the viewer could not render, then it could be ignored, an error could be displayed, or some other geometry could be displayed in it's place. On Sun, May 17, 2009 at 5:03 PM, Tigro Spottystripes < tigrospottystripes at gmail.com> wrote: > a while back I suggested a friend of mine that plays with the client > code (might have been the guy that made flexy sculpties for the first > time, my memory isn't quite clear about that) to modify the client to > read shader programs from notecards in a prim and use the specified > shader on the prim, he told me it was way too complicated to find the > notecards on every prim on screen and associate them with the prim they > are in, not to mention actually implementing such a shader system > > Dale Mahalko escreveu: > > Dahlia, > > > > Actual mesh file format support, through an extensible asset storage > > interface, using notecards for extended support of new datatypes not > > officially approved by LL? What a concept. > > > > Actually I've been thinking about an extensible asset storage method > > for a while. This would allow people to develop new client features > > that go way above and beyond what asset types LL directly supports, to > > splice in whatever 3D or other object support they want. NURBS, whatever. > > > > Just as long as notecards can handle binary data rather than plain > > text -- or use something like yEnc on usenet for putting raw binary > > into notecards. Just segment the data across chains of notecards, as > > in actual Usenet postings. Do we next throw in PAR encoding for when > > all the notecards don't load? ;-) > > > > Heck, don't even need LL approval to do this, as long as the new > > exentisible asset storage is compatible with the existing notecard > > data type. (I can hear a dozen Lindens going.. whoah... whoah... slow > > down..) > > - Dale Mahalko / Scalar Tardis > > > > > > On Sun, May 17, 2009 at 6:39 PM, Dahlia Trimble > > > wrote: > > > > How about just putting the text of a .obj file into a notecard and > > using that? It would be compatible with the current asset system. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20090517/86b5efc7/attachment.htm From nexiim at googlemail.com Sun May 17 19:16:30 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Mon, 18 May 2009 03:16:30 +0100 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <4A107003.1030808@boroon.dasgupta.ch> References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> <4A107003.1030808@boroon.dasgupta.ch> Message-ID: <824c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com> I think rather than keeping the problem on the LSL side, it would be more suitable for being a viewer-side feature entirely that replaced the necessity of such silly HUDs and Gadgets. Finally removing the source of the problem alltogether, and virally so due to the big advantages of being able to be tied into the user interface. - Nexii Malthus On Sun, May 17, 2009 at 9:13 PM, Boroondas Gupte wrote: > malachi at tamzap.com schrieb: > > we already know that the simulator holds the data of who is there and > > when. and given the recent addition to the lsl language for > > llGetRegionAgentCount() wouldnt it be just as easy to add some > > function to return the agent keys that are present on the region. this > > would eliminate the use of all probe scanners. and ultimately increase > > the performance of the region. > > > > [...] > > > > if this is possible could someone explain it more in detail about how > > to get started on doing this. a patch perhaps? > As most of the server side of Second Life is still closed source, only > Linden Lab could implement such an sim-to-LSL interface. > http://jira.secondlife.com/browse/SVC-58 seems to be what you request, > so you might want to vote for it. > > If the data should actually be displayed to the end user and a script is > just used to fetch it (e.g. for display on a HUD), that could very well > be replaced by new functionality of the viewer, which is aware of other > avatars on the same sim even outside of draw distance (the data is > needed for the mini-map anyway). To see what's possible there, have a > look at Dale Glass' modifications to the viewer: > http://wiki.secondlife.com/wiki/Alternate_viewers#Dale_Glass_Edition > > Of course, if the data for some reason has to be processed in a sim-side > script and LL doesn't implement SVC-58, you could still get a modified > viewer (or a bot) to transfer it back inworld via hidden chat channels. > http://wiki.secondlife.com/wiki/Alternate_viewers#Marine_Edition uses > this technique. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090518/f695284d/attachment.htm From tateru.nino at gmail.com Sun May 17 19:27:14 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon, 18 May 2009 12:27:14 +1000 Subject: [sldev] Extensible Asset Data Format (Re: Hide geometry) In-Reply-To: References: Message-ID: <4A10C782.6010909@gmail.com> Notecards are a particularly rough storage choice if I understand the way they're stored and retrieved. Dale Mahalko wrote: > Dahlia, > Actual mesh file format support, through an extensible asset storage > interface, using notecards for extended support of new datatypes not > officially approved by LL? What a concept. > Actually I've been thinking about an extensible asset storage method > for a while. This would allow people to develop new client features > that go way above and beyond what asset types LL directly supports, to > splice in whatever 3D or other object support they want. NURBS, whatever. > Just as long as notecards can handle binary data rather than plain > text -- or use something like yEnc on usenet for putting raw binary > into notecards. Just segment the data across chains of notecards, as > in actual Usenet postings. Do we next throw in PAR encoding for when > all the notecards don't load? ;-) > Heck, don't even need LL approval to do this, as long as the new > exentisible asset storage is compatible with the existing notecard > data type. (I can hear a dozen Lindens going.. whoah... whoah... slow > down..) > - Dale Mahalko / Scalar Tardis > > On Sun, May 17, 2009 at 6:39 PM, Dahlia Trimble > > wrote: > > How about just putting the text of a .obj file into a notecard and > using that? It would be compatible with the current asset system. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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://www.massively.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090518/de94d801/attachment.htm From GordonWendt at gmail.com Sun May 17 19:40:03 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Sun, 17 May 2009 22:40:03 -0400 Subject: [sldev] Extensible Asset Data Format (Re: Hide geometry) In-Reply-To: <4A10C782.6010909@gmail.com> References: <4A10C782.6010909@gmail.com> Message-ID: <493033a70905171940j41e849dbr9522b7b0eafe71fa@mail.gmail.com> If I understand how it's been described before correctly using notecards as script storage in the way their currently implemented is impossible since each save creates a new asset. The previous statement being said having a flexible and non-volatile storage format is very necessary and should be LL's top priority when it comes to the scripting system and a high priority overall. We need a system that is fully read/write and one that can preferably be shared among multiple scripts in an object and/or linkset (with proper permisions controls of course) and scripting is severely hampred until this can be implemented. -Gordon On Sun, May 17, 2009 at 10:27 PM, Tateru Nino wrote: > Notecards are a particularly rough storage choice if I understand the way > they're stored and retrieved. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090517/3d564b2b/attachment.htm From tigrospottystripes at gmail.com Sun May 17 19:44:00 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 17 May 2009 23:44:00 -0300 Subject: [sldev] Extensible Asset Data Format (Re: Hide geometry) In-Reply-To: <493033a70905171940j41e849dbr9522b7b0eafe71fa@mail.gmail.com> References: <4A10C782.6010909@gmail.com> <493033a70905171940j41e849dbr9522b7b0eafe71fa@mail.gmail.com> Message-ID: <4A10CB70.60405@Gmail.com> how about http://jira.secondlife.com/browse/SVC-3143 ? From tigrospottystripes at gmail.com Sun May 17 20:09:10 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 18 May 2009 00:09:10 -0300 Subject: [sldev] Extensible Asset Data Format (Re: Hide geometry) In-Reply-To: <493033a70905171940j41e849dbr9522b7b0eafe71fa@mail.gmail.com> References: <4A10C782.6010909@gmail.com> <493033a70905171940j41e849dbr9522b7b0eafe71fa@mail.gmail.com> Message-ID: <4A10D156.4030009@Gmail.com> actually it seems there is already quite a bite more thought put into yhis topic already on the wiki: http://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL , though it is not exactly like what the proposal I linked earlier is like, it does seems promising From GordonWendt at gmail.com Sun May 17 23:31:36 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon, 18 May 2009 02:31:36 -0400 Subject: [sldev] New HTTP-texture build -- build 2283 Message-ID: <493033a70905172331h33916268y84272e0fb7b08b2f@mail.gmail.com> Not entirely sure if it was because I requested it (thanks either way to whichever Linden did the build) but there's a new build out. It's reported as build 2283. Links are below and it seems that only Lindens can edit the wiki page that has the listings so the Open Source Portal page links are out of date and are to an older build until a Linden gets the chance to update them. Linux: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2283/SecondLife-i686-1.23.2.2283.tar.bz2 http://secondlife.com/developers/opensource/downloads/2009/http-texture/2283/good-build.Linux Darwin: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2283/SecondLife_1_23_2_2283_OSS.dmg http://secondlife.com/developers/opensource/downloads/2009/http-texture/2283/good-build.Darwin CYGWIN: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2283/Second_Life_1-23-2-2283_OSS_Setup.exe http://secondlife.com/developers/opensource/downloads/2009/http-texture/2283/good-build.CYGWIN -Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090518/08042bb5/attachment.htm From GordonWendt at gmail.com Sun May 17 23:35:47 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon, 18 May 2009 02:35:47 -0400 Subject: [sldev] New HTTP-texture build -- build 2283 In-Reply-To: <493033a70905172331h33916268y84272e0fb7b08b2f@mail.gmail.com> References: <493033a70905172331h33916268y84272e0fb7b08b2f@mail.gmail.com> Message-ID: <493033a70905172335q319ee8c1r40faeae5f314aecd@mail.gmail.com> Correction from before, apparently the wiki page can be edited so I took the liberty of updating that. -Gordon On Mon, May 18, 2009 at 2:31 AM, Gordon Wendt wrote: > Not entirely sure if it was because I requested it (thanks either way to > whichever Linden did the build) but there's a new build out. It's reported > as build 2283. Links are below and it seems that only Lindens can edit the > wiki page that has the listings so the Open Source Portal page links are out > of date and are to an older build until a Linden gets the chance to update > them. > > Linux: > > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2283/SecondLife-i686-1.23.2.2283.tar.bz2 > > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2283/good-build.Linux > > Darwin: > > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2283/SecondLife_1_23_2_2283_OSS.dmg > > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2283/good-build.Darwin > > CYGWIN: > > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2283/Second_Life_1-23-2-2283_OSS_Setup.exe > > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2283/good-build.CYGWIN > > -Gordon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090518/6316e534/attachment.htm From chaosstar at gmail.com Mon May 18 04:16:29 2009 From: chaosstar at gmail.com (Ambrosia) Date: Mon, 18 May 2009 13:16:29 +0200 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <824c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com> References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> <4A107003.1030808@boroon.dasgupta.ch> <824c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com> Message-ID: <9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com> On Mon, May 18, 2009 at 04:16, Nexii Malthus wrote: > I think rather than keeping the problem on the LSL side, it would be more > suitable for being a viewer-side feature entirely that replaced the > necessity of such silly HUDs and Gadgets. Finally removing the source of the > problem alltogether, and virally so due to the big advantages of being able > to be tied into the user interface. > > - Nexii Malthus Which would not remove, at all, the problem of having to use sensors in an object in order for the object to detect who is nearby. It would be much more feasable to have a function return a list of avatar keys in the sim, and to call this function once whenever the agent count in the region changes. From drakth at gmail.com Mon May 18 03:24:55 2009 From: drakth at gmail.com (Drakth) Date: Mon, 18 May 2009 12:24:55 +0200 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com> References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> <4A107003.1030808@boroon.dasgupta.ch> <824c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com> <9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com> Message-ID: <4A113777.7040603@gmail.com> There are several post in JIRA requesting a new feature to get the avatar keys in a simulator: http://jira.secondlife.com/browse/SVC-215 http://jira.secondlife.com/browse/SVC-805 http://jira.secondlife.com/browse/VWR-11683 maybe there are more but those are the ones im aware of. Indeed this new feature would remove the need of probes for simscanners, reducing lag, but LL doesnt seem interested to make it happen. Feel free to vote them!. Ambrosia wrote: > On Mon, May 18, 2009 at 04:16, Nexii Malthus wrote: > >> I think rather than keeping the problem on the LSL side, it would be more >> suitable for being a viewer-side feature entirely that replaced the >> necessity of such silly HUDs and Gadgets. Finally removing the source of the >> problem alltogether, and virally so due to the big advantages of being able >> to be tied into the user interface. >> >> - Nexii Malthus >> > > Which would not remove, at all, the problem of having to use sensors > in an object in order for the object to detect who is nearby. It would > be much more feasable to have a function return a list of avatar keys > in the sim, and to call this function once whenever the agent count in > the region changes. > _______________________________________________ > 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 Mon May 18 09:43:19 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Mon, 18 May 2009 09:43:19 -0700 Subject: [sldev] New HTTP-texture build -- build 2283 In-Reply-To: <493033a70905172331h33916268y84272e0fb7b08b2f@mail.gmail.com> References: <493033a70905172331h33916268y84272e0fb7b08b2f@mail.gmail.com> Message-ID: <4A119027.4010906@lindenlab.com> On 05/17/2009 11:31 PM, Gordon Wendt wrote: > Not entirely sure if it was because I requested it (thanks either way > to whichever Linden did the build) but there's a new build out. You're welcome :) (I saw your ping on #opensl) > It's reported as build 2283. Yup. The only change between this build and the previous build (2259) is Aimee's updated patch for VWR-8008. http://svn.secondlife.com/trac/linden/changeset/2283 You can see the revision log for this branch (or access the RSS feed for this branch) here: http://svn.secondlife.com/trac/linden/log/projects/2009/http-texture Links are off this page: https://wiki.secondlife.com/wiki/Open_Source_Portal Rob From sldev at free.fr Mon May 18 12:11:30 2009 From: sldev at free.fr (Henri Beauchamp) Date: Mon, 18 May 2009 21:11:30 +0200 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com> References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> <4A107003.1030808@boroon.dasgupta.ch> <824c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com> <9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com> Message-ID: <20090518211130.04e51ce9.sldev@free.fr> On Mon, 18 May 2009 13:16:29 +0200, Ambrosia wrote: > On Mon, May 18, 2009 at 04:16, Nexii Malthus wrote: > > I think rather than keeping the problem on the LSL side, it would be more > > suitable for being a viewer-side feature entirely that replaced the > > necessity of such silly HUDs and Gadgets. Finally removing the source of the > > problem alltogether, and virally so due to the big advantages of being able > > to be tied into the user interface. > > > > - Nexii Malthus > > Which would not remove, at all, the problem of having to use sensors > in an object in order for the object to detect who is nearby. It would > be much more feasable to have a function return a list of avatar keys > in the sim, and to call this function once whenever the agent count in > the region changes. I think the best solution would be to allow sim-wide sensors (llRegionSensor() ?)... This would remove the need for probes, just like llRegionSay() suppressed the need for llShout() relays in the sims... Henri. From kelly at lindenlab.com Mon May 18 13:03:35 2009 From: kelly at lindenlab.com (Kelly) Date: Mon, 18 May 2009 13:03:35 -0700 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <20090518211130.04e51ce9.sldev@free.fr> References: <4A0F5CE5.2090307@gmail.com><4A0FA697.2050706@gmail.com><4A107003.1030808@boroon.dasgupta.ch><8 24c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com><9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com> <20090518211130.04e51ce9.sldev@free.fr> Message-ID: <4A11BF17.8060002@lindenlab.com> Henri Beauchamp wrote: > On Mon, 18 May 2009 13:16:29 +0200, Ambrosia wrote: > > >> On Mon, May 18, 2009 at 04:16, Nexii Malthus wrote: >> >>> I think rather than keeping the problem on the LSL side, it would be more >>> suitable for being a viewer-side feature entirely that replaced the >>> necessity of such silly HUDs and Gadgets. Finally removing the source of the >>> problem alltogether, and virally so due to the big advantages of being able >>> to be tied into the user interface. >>> >>> - Nexii Malthus >>> >> Which would not remove, at all, the problem of having to use sensors >> in an object in order for the object to detect who is nearby. It would >> be much more feasable to have a function return a list of avatar keys >> in the sim, and to call this function once whenever the agent count in >> the region changes. >> > > I think the best solution would be to allow sim-wide sensors > (llRegionSensor() ?)... This would remove the need for probes, just like > llRegionSay() suppressed the need for llShout() relays in the sims... > > Henri. > Sensor events are kind of weird. They were designed specifically to give a real-world quality to gathered data. If you have a sensor in the real world, the data it can pick up is generally directly related to where the object is and some range that it can sense information, and probably a direction. There are definitely uses for this kind of information gathering in Second Life, "what objects are near me" and the various permutations thereof are definitely useful. However they do have problems. They are limited in what data they collect since they scan and store a snapshot of the data with the script - we can't really extend how many results or what data is gathered just because of the memory footprint involved. The legacy script formats add additional difficulties that are less insurmountable but still trouble. By their nature they are at least a little more load intensive than just accessing data the region already has in memory would be. If you extrapolate from this just a little bit you can think about why region wide sensors wouldn't be that great. We could still only return the 16 results and the existing types of data. As has already been suggested in this thread I believe, we are much more likely to investigate non-sensor calls that directly access information the region already has in memory and don't try to mimic real world behaviors or the sensor pattern. llGetAgentCount() or llGetAgentsInParcel for example, that could return data directly. I'm not saying we are working on these or even have plans for them, and there may be privacy issues that come into play for some of these types of calls. I'm just saying that I think this is more likely to be the direction we head than extending or mimicking the llSensor pattern. - Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090518/29729d65/attachment.htm From malachi at tamzap.com Mon May 18 13:31:08 2009 From: malachi at tamzap.com (malachi at tamzap.com) Date: Mon, 18 May 2009 16:31:08 -0400 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <4A11BF17.8060002@lindenlab.com> References: <4A0F5CE5.2090307@gmail.com><4A0FA697.2050706@gmail.com><4A107003.1030808@boroon.dasgupta.ch><824c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com><9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com><20090518211130.04e51ce9.sldev@free.fr> <4A11BF17.8060002@lindenlab.com> Message-ID: <32FB96532FEA4888BBA7C72FBD038442@slsystemspc> Kelly, what privacy issues are you speaking of.. because as it stands agents are already using sim crippling scanner probes that report the entire list of keys in a region even to the point of upto 100,000m in altitude. and the lag produced by these probes is horrible.if there is a privacy issue then its already been violated by the standard llSensor calls. i was only suggesting a way to help bring resource use down by implementing a call to the server to get the list of agent keys in the region eliminating the need for probes flying all over the sim to get data that is already there. i understand that people dont want to be seen on sensors because they are afraid they may be attacked by griefers using the technology. but we already have the ability to find them on the sim no matter where they are hidden... the only fault in it as it is is that is crushes sim resources and makes the general experience for the regions users less than acceptable. my post was ment only to see if any linden or other developer was intrested in helping cure the grid of these lag monsters. regards, mal ----- Original Message ----- From: Kelly To: Henri Beauchamp Cc: sldev at lists.secondlife.com Sent: Monday, May 18, 2009 4:03 PM Subject: Re: [sldev] A thought on how to lower resources used by sensors Henri Beauchamp wrote: On Mon, 18 May 2009 13:16:29 +0200, Ambrosia wrote: On Mon, May 18, 2009 at 04:16, Nexii Malthus wrote: I think rather than keeping the problem on the LSL side, it would be more suitable for being a viewer-side feature entirely that replaced the necessity of such silly HUDs and Gadgets. Finally removing the source of the problem alltogether, and virally so due to the big advantages of being able to be tied into the user interface. - Nexii Malthus Which would not remove, at all, the problem of having to use sensors in an object in order for the object to detect who is nearby. It would be much more feasable to have a function return a list of avatar keys in the sim, and to call this function once whenever the agent count in the region changes. I think the best solution would be to allow sim-wide sensors (llRegionSensor() ?)... This would remove the need for probes, just like llRegionSay() suppressed the need for llShout() relays in the sims... Henri. Sensor events are kind of weird. They were designed specifically to give a real-world quality to gathered data. If you have a sensor in the real world, the data it can pick up is generally directly related to where the object is and some range that it can sense information, and probably a direction. There are definitely uses for this kind of information gathering in Second Life, "what objects are near me" and the various permutations thereof are definitely useful. However they do have problems. They are limited in what data they collect since they scan and store a snapshot of the data with the script - we can't really extend how many results or what data is gathered just because of the memory footprint involved. The legacy script formats add additional difficulties that are less insurmountable but still trouble. By their nature they are at least a little more load intensive than just accessing data the region already has in memory would be. If you extrapolate from this just a little bit you can think about why region wide sensors wouldn't be that great. We could still only return the 16 results and the existing types of data. As has already been suggested in this thread I believe, we are much more likely to investigate non-sensor calls that directly access information the region already has in memory and don't try to mimic real world behaviors or the sensor pattern. llGetAgentCount() or llGetAgentsInParcel for example, that could return data directly. I'm not saying we are working on these or even have plans for them, and there may be privacy issues that come into play for some of these types of calls. I'm just saying that I think this is more likely to be the direction we head than extending or mimicking the llSensor pattern. - Kelly ------------------------------------------------------------------------------ _______________________________________________ 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/20090518/4846b455/attachment.htm From tom at streamsense.net Mon May 18 13:39:56 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Mon, 18 May 2009 21:39:56 +0100 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <32FB96532FEA4888BBA7C72FBD038442@slsystemspc> References: <4A0F5CE5.2090307@gmail.com><4A0FA697.2050706@gmail.com><4A107003.1030808@boroon.dasgupta.ch><824c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com><9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com><20090518211130.04e51ce9.sldev@free.fr> <4A11BF17.8060002@lindenlab.com> <32FB96532FEA4888BBA7C72FBD038442@slsystemspc> Message-ID: <4A11C79C.8070604@streamsense.net> The probes can only uperate at up to 4,096m and can scan 96m higher than that.. But the point is still absolutely valid. It's already perfectly easy and possible to scan an entire sim, and everyone I know has a radar which does this. Absolutely +1 for unrestricting sensor range. Whoever initially implemented this restriction was an idiot. :/ ~T malachi at tamzap.com wrote: > Kelly, > > what privacy issues are you speaking of.. because as it stands agents > are already using sim crippling scanner probes that report the entire > list of keys in a region even to the point of upto 100,000m in > altitude. and the lag produced by these probes is horrible.if there is > a privacy issue then its already been violated by the standard > llSensor calls. i was only suggesting a way to help bring resource use > down by implementing a call to the server to get the list of agent > keys in the region eliminating the need for probes flying all over the > sim to get data that is already there. > > i understand that people dont want to be seen on sensors because they > are afraid they may be attacked by griefers using the technology. but > we already have the ability to find them on the sim no matter where > they are hidden... the only fault in it as it is is that is crushes > sim resources and makes the general experience for the regions users > less than acceptable. > > my post was ment only to see if any linden or other developer was > intrested in helping cure the grid of these lag monsters. > > regards, > mal > > ----- Original Message ----- > *From:* Kelly > *To:* Henri Beauchamp > *Cc:* sldev at lists.secondlife.com > *Sent:* Monday, May 18, 2009 4:03 PM > *Subject:* Re: [sldev] A thought on how to lower resources used by > sensors > > Henri Beauchamp wrote: >> On Mon, 18 May 2009 13:16:29 +0200, Ambrosia wrote: >> >> >>> On Mon, May 18, 2009 at 04:16, Nexii Malthus wrote: >>> >>>> I think rather than keeping the problem on the LSL side, it would be more >>>> suitable for being a viewer-side feature entirely that replaced the >>>> necessity of such silly HUDs and Gadgets. Finally removing the source of the >>>> problem alltogether, and virally so due to the big advantages of being able >>>> to be tied into the user interface. >>>> >>>> - Nexii Malthus >>>> >>> Which would not remove, at all, the problem of having to use sensors >>> in an object in order for the object to detect who is nearby. It would >>> be much more feasable to have a function return a list of avatar keys >>> in the sim, and to call this function once whenever the agent count in >>> the region changes. >>> >> >> I think the best solution would be to allow sim-wide sensors >> (llRegionSensor() ?)... This would remove the need for probes, just like >> llRegionSay() suppressed the need for llShout() relays in the sims... >> >> Henri. >> > Sensor events are kind of weird. They were designed specifically > to give a real-world quality to gathered data. If you have a > sensor in the real world, the data it can pick up is generally > directly related to where the object is and some range that it can > sense information, and probably a direction. There are definitely > uses for this kind of information gathering in Second Life, "what > objects are near me" and the various permutations thereof are > definitely useful. > > However they do have problems. They are limited in what data they > collect since they scan and store a snapshot of the data with the > script - we can't really extend how many results or what data is > gathered just because of the memory footprint involved. The > legacy script formats add additional difficulties that are less > insurmountable but still trouble. By their nature they are at > least a little more load intensive than just accessing data the > region already has in memory would be. If you extrapolate from > this just a little bit you can think about why region wide sensors > wouldn't be that great. We could still only return the 16 results > and the existing types of data. > > As has already been suggested in this thread I believe, we are > much more likely to investigate non-sensor calls that directly > access information the region already has in memory and don't try > to mimic real world behaviors or the sensor pattern. > llGetAgentCount() or llGetAgentsInParcel for example, that could > return data directly. I'm not saying we are working on these or > even have plans for them, and there may be privacy issues that > come into play for some of these types of calls. I'm just saying > that I think this is more likely to be the direction we head than > extending or mimicking the llSensor pattern. > > - Kelly > > ------------------------------------------------------------------------ > _______________________________________________ > 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 q at lindenlab.com Mon May 18 13:50:09 2009 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Mon, 18 May 2009 16:50:09 -0400 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <4A11C79C.8070604@streamsense.net> References: <4A0F5CE5.2090307@gmail.com><4A0FA697.2050706@gmail.com><4A107003.1030808@boroon.dasgupta.ch><8 24c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com><9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com><2009051 8211130.04e51ce9.sldev@free.fr> <4A11BF17.8060002@lindenlab.com><32FB96532FEA4888BBA7C72FBD038442@slsystemspc> <4A11C79C.8070604@streamsense.net> Message-ID: Ya know, I'm all for creative discussion, and certainly there's plenty of criticism to go around. But I've seen an increase in ad hominem attacks. In this particular case, I'm betting that the person who coded the restriction was not an idiot (and no, I don't know who it was), nor do I think it's all that obvious that the decision was even a poor one. We may be learning that in practice the restriction causes more problems than it solves, but it would make it a lot easier for those of us at Linden to have intelligent conversations if the people we're conversing with were at least trying to be polite. Q On May 18, 2009, at 4:39 PM, Thomas Grimshaw wrote: > The probes can only uperate at up to 4,096m and can scan 96m higher > than > that.. > > But the point is still absolutely valid. It's already perfectly easy > and > possible to scan an entire sim, and everyone I know has a radar which > does this. > > Absolutely +1 for unrestricting sensor range. Whoever initially > implemented this restriction was an idiot. :/ > > ~T > > malachi at tamzap.com wrote: >> Kelly, >> >> what privacy issues are you speaking of.. because as it stands agents >> are already using sim crippling scanner probes that report the entire >> list of keys in a region even to the point of upto 100,000m in >> altitude. and the lag produced by these probes is horrible.if there >> is >> a privacy issue then its already been violated by the standard >> llSensor calls. i was only suggesting a way to help bring resource >> use >> down by implementing a call to the server to get the list of agent >> keys in the region eliminating the need for probes flying all over >> the >> sim to get data that is already there. >> >> i understand that people dont want to be seen on sensors because they >> are afraid they may be attacked by griefers using the technology. but >> we already have the ability to find them on the sim no matter where >> they are hidden... the only fault in it as it is is that is crushes >> sim resources and makes the general experience for the regions users >> less than acceptable. >> >> my post was ment only to see if any linden or other developer was >> intrested in helping cure the grid of these lag monsters. >> >> regards, >> mal >> >> ----- Original Message ----- >> *From:* Kelly >> *To:* Henri Beauchamp >> *Cc:* sldev at lists.secondlife.com > > >> *Sent:* Monday, May 18, 2009 4:03 PM >> *Subject:* Re: [sldev] A thought on how to lower resources used by >> sensors >> >> Henri Beauchamp wrote: >>> On Mon, 18 May 2009 13:16:29 +0200, Ambrosia wrote: >>> >>> >>>> On Mon, May 18, 2009 at 04:16, Nexii Malthus >>> > wrote: >>>> >>>>> I think rather than keeping the problem on the LSL side, it >>>>> would be more >>>>> suitable for being a viewer-side feature entirely that >>>>> replaced the >>>>> necessity of such silly HUDs and Gadgets. Finally removing >>>>> the source of the >>>>> problem alltogether, and virally so due to the big advantages >>>>> of being able >>>>> to be tied into the user interface. >>>>> >>>>> - Nexii Malthus >>>>> >>>> Which would not remove, at all, the problem of having to use >>>> sensors >>>> in an object in order for the object to detect who is nearby. >>>> It would >>>> be much more feasable to have a function return a list of >>>> avatar keys >>>> in the sim, and to call this function once whenever the agent >>>> count in >>>> the region changes. >>>> >>> >>> I think the best solution would be to allow sim-wide sensors >>> (llRegionSensor() ?)... This would remove the need for probes, >>> just like >>> llRegionSay() suppressed the need for llShout() relays in the >>> sims... >>> >>> Henri. >>> >> Sensor events are kind of weird. They were designed specifically >> to give a real-world quality to gathered data. If you have a >> sensor in the real world, the data it can pick up is generally >> directly related to where the object is and some range that it can >> sense information, and probably a direction. There are definitely >> uses for this kind of information gathering in Second Life, "what >> objects are near me" and the various permutations thereof are >> definitely useful. >> >> However they do have problems. They are limited in what data they >> collect since they scan and store a snapshot of the data with the >> script - we can't really extend how many results or what data is >> gathered just because of the memory footprint involved. The >> legacy script formats add additional difficulties that are less >> insurmountable but still trouble. By their nature they are at >> least a little more load intensive than just accessing data the >> region already has in memory would be. If you extrapolate from >> this just a little bit you can think about why region wide sensors >> wouldn't be that great. We could still only return the 16 results >> and the existing types of data. >> >> As has already been suggested in this thread I believe, we are >> much more likely to investigate non-sensor calls that directly >> access information the region already has in memory and don't try >> to mimic real world behaviors or the sensor pattern. >> llGetAgentCount() or llGetAgentsInParcel for example, that could >> return data directly. I'm not saying we are working on these or >> even have plans for them, and there may be privacy issues that >> come into play for some of these types of calls. I'm just saying >> that I think this is more likely to be the direction we head than >> extending or mimicking the llSensor pattern. >> >> - Kelly >> >> >> ------------------------------------------------------------------------ >> _______________________________________________ >> 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 ordinal.malaprop at fastmail.fm Mon May 18 13:55:51 2009 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop at fastmail.fm) Date: Mon, 18 May 2009 21:55:51 +0100 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <4A11C79C.8070604@streamsense.net> References: <4A0F5CE5.2090307@gmail.com><4A0FA697.2050706@gmail.com><4A107003.1030808@boroon.dasgupta.ch><824c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com><9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com><20090518211130.04e51ce9.sldev@free.fr> <4A11BF17.8060002@lindenlab.com> <32FB96532FEA4888BBA7C72FBD038442@slsystemspc> <4A11C79C.8070604@streamsense.net> Message-ID: <85F075DF-9FD3-4858-90B5-ADE12F1E99D4@fastmail.fm> I do quite like the idea that scripts can only detect things in range, actually, it has a certain "fairness" to it and it is appropriate to times when we all lived on the mainland and shared the environment. But then, so were telehubs. And things have gone beyond the point where knowing who is there is only appropriate within sensor range, because there are so many other functions which don't care. Firstly there is the open-sourced client, which as has been said knows who is in which sim, but secondly there are lots of sim-wide LSL functions now such as llGetObjectDetails and llRegionSay which don't care how far away you are. It used to be the case that to track somebody a script had to be within 96m and have fewer than 16 people in-between; that isn't the case any more, and a good thing too, as llGetObjectDetails is _far_ more efficient. It also has not kept up with changes in the style of land ownership, particularly private or single-owner sims which may be themed and where the owners and visitors wish to have certain sim-wide systems operating. I have an openspace myself, where I have systems running that require me to know who is there, and it is ridiculous that while I can track them endlessly once I know they have entered, to find out whether they are there at all initially requires me to have a sensor grid. The main complaints when I have seen proposals on this theme seem to come from one or two developers of "shields" who use hacks to keep avatars out of sensors, and quite honestly this is not enough to count as unacceptable broken content in my opinion, particularly as so many "shields" are abusive anyway. On 18 May 2009, at 21:39, Thomas Grimshaw wrote: > The probes can only uperate at up to 4,096m and can scan 96m higher > than > that.. > > But the point is still absolutely valid. It's already perfectly easy > and > possible to scan an entire sim, and everyone I know has a radar which > does this. > > Absolutely +1 for unrestricting sensor range. Whoever initially > implemented this restriction was an idiot. :/ > > ~T > > malachi at tamzap.com wrote: >> Kelly, >> >> what privacy issues are you speaking of.. because as it stands agents >> are already using sim crippling scanner probes that report the entire >> list of keys in a region even to the point of upto 100,000m in >> altitude. and the lag produced by these probes is horrible.if there >> is >> a privacy issue then its already been violated by the standard >> llSensor calls. i was only suggesting a way to help bring resource >> use >> down by implementing a call to the server to get the list of agent >> keys in the region eliminating the need for probes flying all over >> the >> sim to get data that is already there. >> >> i understand that people dont want to be seen on sensors because they >> are afraid they may be attacked by griefers using the technology. but >> we already have the ability to find them on the sim no matter where >> they are hidden... the only fault in it as it is is that is crushes >> sim resources and makes the general experience for the regions users >> less than acceptable. >> >> my post was ment only to see if any linden or other developer was >> intrested in helping cure the grid of these lag monsters. >> >> regards, >> mal >> >> ----- Original Message ----- >> *From:* Kelly >> *To:* Henri Beauchamp >> *Cc:* sldev at lists.secondlife.com > > >> *Sent:* Monday, May 18, 2009 4:03 PM >> *Subject:* Re: [sldev] A thought on how to lower resources used by >> sensors >> >> Henri Beauchamp wrote: >>> On Mon, 18 May 2009 13:16:29 +0200, Ambrosia wrote: >>> >>> >>>> On Mon, May 18, 2009 at 04:16, Nexii Malthus >>> > wrote: >>>> >>>>> I think rather than keeping the problem on the LSL side, it >>>>> would be more >>>>> suitable for being a viewer-side feature entirely that >>>>> replaced the >>>>> necessity of such silly HUDs and Gadgets. Finally removing >>>>> the source of the >>>>> problem alltogether, and virally so due to the big advantages >>>>> of being able >>>>> to be tied into the user interface. >>>>> >>>>> - Nexii Malthus >>>>> >>>> Which would not remove, at all, the problem of having to use >>>> sensors >>>> in an object in order for the object to detect who is nearby. >>>> It would >>>> be much more feasable to have a function return a list of >>>> avatar keys >>>> in the sim, and to call this function once whenever the agent >>>> count in >>>> the region changes. >>>> >>> >>> I think the best solution would be to allow sim-wide sensors >>> (llRegionSensor() ?)... This would remove the need for probes, >>> just like >>> llRegionSay() suppressed the need for llShout() relays in the >>> sims... >>> >>> Henri. >>> >> Sensor events are kind of weird. They were designed specifically >> to give a real-world quality to gathered data. If you have a >> sensor in the real world, the data it can pick up is generally >> directly related to where the object is and some range that it can >> sense information, and probably a direction. There are definitely >> uses for this kind of information gathering in Second Life, "what >> objects are near me" and the various permutations thereof are >> definitely useful. >> >> However they do have problems. They are limited in what data they >> collect since they scan and store a snapshot of the data with the >> script - we can't really extend how many results or what data is >> gathered just because of the memory footprint involved. The >> legacy script formats add additional difficulties that are less >> insurmountable but still trouble. By their nature they are at >> least a little more load intensive than just accessing data the >> region already has in memory would be. If you extrapolate from >> this just a little bit you can think about why region wide sensors >> wouldn't be that great. We could still only return the 16 results >> and the existing types of data. >> >> As has already been suggested in this thread I believe, we are >> much more likely to investigate non-sensor calls that directly >> access information the region already has in memory and don't try >> to mimic real world behaviors or the sensor pattern. >> llGetAgentCount() or llGetAgentsInParcel for example, that could >> return data directly. I'm not saying we are working on these or >> even have plans for them, and there may be privacy issues that >> come into play for some of these types of calls. I'm just saying >> that I think this is more likely to be the direction we head than >> extending or mimicking the llSensor pattern. >> >> - Kelly >> >> >> ------------------------------------------------------------------------ >> _______________________________________________ >> 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 kelly at lindenlab.com Mon May 18 13:56:55 2009 From: kelly at lindenlab.com (Kelly) Date: Mon, 18 May 2009 13:56:55 -0700 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <4A11C79C.8070604@streamsense.net> References: <4A0F5CE5.2090307@gmail.com><4A0FA697.2050706@gmail.com><4A107003.1030808@boroon.dasgupta.ch><8 24c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com><9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com><2009051 8211130.04e51ce9.sldev@free.fr> <4A11BF17.8060002@lindenlab.com><32FB96532FEA4888BBA7C72FBD038442@slsystemspc> <4A11C79C.8070604@streamsense.net> Message-ID: <4A11CB97.9000900@lindenlab.com> Sorry Malachi, I think my spam filter is picking up your emails. :( Anyway. I put that in there because any time we add new data collection LSL calls privacy issues are something we have to think about. Maybe you are right and there are none. Maybe we need to make sure these calls only work if the script/object owner are on the parcel or the parcel owner or some other criteria. I don't mean to enter that debate here or to derail the initial conversation. I only mean that it is one factor that has to be taken into consideration for this kind of call. Sorry if mentioning it caused confusion. The point is that going forward we will probably prefer methods that just return data readily available from the region process rather than calls that use llSensor or follow that pattern. - Kelly Thomas Grimshaw wrote: > The probes can only uperate at up to 4,096m and can scan 96m higher than > that.. > > But the point is still absolutely valid. It's already perfectly easy and > possible to scan an entire sim, and everyone I know has a radar which > does this. > > Absolutely +1 for unrestricting sensor range. Whoever initially > implemented this restriction was an idiot. :/ > > ~T > > malachi at tamzap.com wrote: > >> Kelly, >> >> what privacy issues are you speaking of.. because as it stands agents >> are already using sim crippling scanner probes that report the entire >> list of keys in a region even to the point of upto 100,000m in >> altitude. and the lag produced by these probes is horrible.if there is >> a privacy issue then its already been violated by the standard >> llSensor calls. i was only suggesting a way to help bring resource use >> down by implementing a call to the server to get the list of agent >> keys in the region eliminating the need for probes flying all over the >> sim to get data that is already there. >> >> i understand that people dont want to be seen on sensors because they >> are afraid they may be attacked by griefers using the technology. but >> we already have the ability to find them on the sim no matter where >> they are hidden... the only fault in it as it is is that is crushes >> sim resources and makes the general experience for the regions users >> less than acceptable. >> >> my post was ment only to see if any linden or other developer was >> intrested in helping cure the grid of these lag monsters. >> >> regards, >> mal >> >> ----- Original Message ----- >> *From:* Kelly >> *To:* Henri Beauchamp >> *Cc:* sldev at lists.secondlife.com >> *Sent:* Monday, May 18, 2009 4:03 PM >> *Subject:* Re: [sldev] A thought on how to lower resources used by >> sensors >> >> Henri Beauchamp wrote: >> >>> On Mon, 18 May 2009 13:16:29 +0200, Ambrosia wrote: >>> >>> >>> >>>> On Mon, May 18, 2009 at 04:16, Nexii Malthus wrote: >>>> >>>> >>>>> I think rather than keeping the problem on the LSL side, it would be more >>>>> suitable for being a viewer-side feature entirely that replaced the >>>>> necessity of such silly HUDs and Gadgets. Finally removing the source of the >>>>> problem alltogether, and virally so due to the big advantages of being able >>>>> to be tied into the user interface. >>>>> >>>>> - Nexii Malthus >>>>> >>>>> >>>> Which would not remove, at all, the problem of having to use sensors >>>> in an object in order for the object to detect who is nearby. It would >>>> be much more feasable to have a function return a list of avatar keys >>>> in the sim, and to call this function once whenever the agent count in >>>> the region changes. >>>> >>>> >>> I think the best solution would be to allow sim-wide sensors >>> (llRegionSensor() ?)... This would remove the need for probes, just like >>> llRegionSay() suppressed the need for llShout() relays in the sims... >>> >>> Henri. >>> >>> >> Sensor events are kind of weird. They were designed specifically >> to give a real-world quality to gathered data. If you have a >> sensor in the real world, the data it can pick up is generally >> directly related to where the object is and some range that it can >> sense information, and probably a direction. There are definitely >> uses for this kind of information gathering in Second Life, "what >> objects are near me" and the various permutations thereof are >> definitely useful. >> >> However they do have problems. They are limited in what data they >> collect since they scan and store a snapshot of the data with the >> script - we can't really extend how many results or what data is >> gathered just because of the memory footprint involved. The >> legacy script formats add additional difficulties that are less >> insurmountable but still trouble. By their nature they are at >> least a little more load intensive than just accessing data the >> region already has in memory would be. If you extrapolate from >> this just a little bit you can think about why region wide sensors >> wouldn't be that great. We could still only return the 16 results >> and the existing types of data. >> >> As has already been suggested in this thread I believe, we are >> much more likely to investigate non-sensor calls that directly >> access information the region already has in memory and don't try >> to mimic real world behaviors or the sensor pattern. >> llGetAgentCount() or llGetAgentsInParcel for example, that could >> return data directly. I'm not saying we are working on these or >> even have plans for them, and there may be privacy issues that >> come into play for some of these types of calls. I'm just saying >> that I think this is more likely to be the direction we head than >> extending or mimicking the llSensor pattern. >> >> - Kelly >> >> ------------------------------------------------------------------------ >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090518/c8a02487/attachment-0001.htm From philip at lindenlab.com Mon May 18 14:24:10 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Mon, 18 May 2009 14:24:10 -0700 Subject: [sldev] New viewer name: Snowglobe Message-ID: <4A11D1FA.9030404@lindenlab.com> Hey all, So 'Snowglobe' is the new name we picked for the new viewer we've all been working on. Seemed clever (just think of the Citizen Kane references), fun, referential to virtual worlds generally, and something that could be effectively mutated for different projects (what you put 'inside' the snowglobe). We've registered it and gotten some domains (snowglobeproject.org, etc). Next step for us/LL is to come up with some art, and flesh out some usage guidelines. So let's start updating the wiki(s) with the new name, and rebranding patches also welcome (VWR-13295). Also any initial design ideas or mockups for art would be great. We're trying to enlist some internal LL folks for art treatments, but anything you want to throw in the ring is welcome. Philip From drakth at gmail.com Mon May 18 14:23:02 2009 From: drakth at gmail.com (Matias A. V.) Date: Mon, 18 May 2009 18:23:02 -0300 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <4A11CB97.9000900@lindenlab.com> References: <4A0F5CE5.2090307@gmail.com><4A0FA697.2050706@gmail.com><4A107003.1030808@boroon.dasgupta.ch><8 24c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com><9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com><2009051 8211130.04e51ce9.sldev@free.fr> <4A11BF17.8060002@lindenlab.com><32FB96532FEA4888BBA7C72FBD038442@slsystemspc> <4A11C79C.8070604@streamsense.net> <4A11CB97.9000900@lindenlab.com> Message-ID: <4A11D1B6.1010008@gmail.com> IMO i dont see any privacies issues, if you want to know if someone is in the sim you just need its key, then you can use llGetObjectDetails to check it. Also there is a plugin called PAR made by lorg greg i think, that tells you everyone in the sim as soon as you enter it, doesnt rez anything doesnt use probes works even in no script land (even if disabled in the estate tools). Also i have recently discover that if you hover the mouse over one of the dots in the minimap it tells you the name of the avatar :P (in the latest RC viewer) so the informacion is already there, IMO a function that returns the key of every agent in the region would help to reduce lag a lot. Kelly wrote: > Sorry Malachi, I think my spam filter is picking up your emails. :( > > Anyway. I put that in there because any time we add new data > collection LSL calls privacy issues are something we have to think > about. Maybe you are right and there are none. Maybe we need to make > sure these calls only work if the script/object owner are on the > parcel or the parcel owner or some other criteria. I don't mean to > enter that debate here or to derail the initial conversation. I only > mean that it is one factor that has to be taken into consideration for > this kind of call. Sorry if mentioning it caused confusion. > > The point is that going forward we will probably prefer methods that > just return data readily available from the region process rather than > calls that use llSensor or follow that pattern. > > - Kelly > > Thomas Grimshaw wrote: >> The probes can only uperate at up to 4,096m and can scan 96m higher than >> that.. >> >> But the point is still absolutely valid. It's already perfectly easy and >> possible to scan an entire sim, and everyone I know has a radar which >> does this. >> >> Absolutely +1 for unrestricting sensor range. Whoever initially >> implemented this restriction was an idiot. :/ >> >> ~T >> >> malachi at tamzap.com wrote: >> >>> Kelly, >>> >>> what privacy issues are you speaking of.. because as it stands agents >>> are already using sim crippling scanner probes that report the entire >>> list of keys in a region even to the point of upto 100,000m in >>> altitude. and the lag produced by these probes is horrible.if there is >>> a privacy issue then its already been violated by the standard >>> llSensor calls. i was only suggesting a way to help bring resource use >>> down by implementing a call to the server to get the list of agent >>> keys in the region eliminating the need for probes flying all over the >>> sim to get data that is already there. >>> >>> i understand that people dont want to be seen on sensors because they >>> are afraid they may be attacked by griefers using the technology. but >>> we already have the ability to find them on the sim no matter where >>> they are hidden... the only fault in it as it is is that is crushes >>> sim resources and makes the general experience for the regions users >>> less than acceptable. >>> >>> my post was ment only to see if any linden or other developer was >>> intrested in helping cure the grid of these lag monsters. >>> >>> regards, >>> mal >>> >>> ----- Original Message ----- >>> *From:* Kelly >>> *To:* Henri Beauchamp >>> *Cc:* sldev at lists.secondlife.com >>> *Sent:* Monday, May 18, 2009 4:03 PM >>> *Subject:* Re: [sldev] A thought on how to lower resources used by >>> sensors >>> >>> Henri Beauchamp wrote: >>> >>>> On Mon, 18 May 2009 13:16:29 +0200, Ambrosia wrote: >>>> >>>> >>>> >>>>> On Mon, May 18, 2009 at 04:16, Nexii Malthus wrote: >>>>> >>>>> >>>>>> I think rather than keeping the problem on the LSL side, it would be more >>>>>> suitable for being a viewer-side feature entirely that replaced the >>>>>> necessity of such silly HUDs and Gadgets. Finally removing the source of the >>>>>> problem alltogether, and virally so due to the big advantages of being able >>>>>> to be tied into the user interface. >>>>>> >>>>>> - Nexii Malthus >>>>>> >>>>>> >>>>> Which would not remove, at all, the problem of having to use sensors >>>>> in an object in order for the object to detect who is nearby. It would >>>>> be much more feasable to have a function return a list of avatar keys >>>>> in the sim, and to call this function once whenever the agent count in >>>>> the region changes. >>>>> >>>>> >>>> I think the best solution would be to allow sim-wide sensors >>>> (llRegionSensor() ?)... This would remove the need for probes, just like >>>> llRegionSay() suppressed the need for llShout() relays in the sims... >>>> >>>> Henri. >>>> >>>> >>> Sensor events are kind of weird. They were designed specifically >>> to give a real-world quality to gathered data. If you have a >>> sensor in the real world, the data it can pick up is generally >>> directly related to where the object is and some range that it can >>> sense information, and probably a direction. There are definitely >>> uses for this kind of information gathering in Second Life, "what >>> objects are near me" and the various permutations thereof are >>> definitely useful. >>> >>> However they do have problems. They are limited in what data they >>> collect since they scan and store a snapshot of the data with the >>> script - we can't really extend how many results or what data is >>> gathered just because of the memory footprint involved. The >>> legacy script formats add additional difficulties that are less >>> insurmountable but still trouble. By their nature they are at >>> least a little more load intensive than just accessing data the >>> region already has in memory would be. If you extrapolate from >>> this just a little bit you can think about why region wide sensors >>> wouldn't be that great. We could still only return the 16 results >>> and the existing types of data. >>> >>> As has already been suggested in this thread I believe, we are >>> much more likely to investigate non-sensor calls that directly >>> access information the region already has in memory and don't try >>> to mimic real world behaviors or the sensor pattern. >>> llGetAgentCount() or llGetAgentsInParcel for example, that could >>> return data directly. I'm not saying we are working on these or >>> even have plans for them, and there may be privacy issues that >>> come into play for some of these types of calls. I'm just saying >>> that I think this is more likely to be the direction we head than >>> extending or mimicking the llSensor pattern. >>> >>> - Kelly >>> >>> ------------------------------------------------------------------------ >>> _______________________________________________ >>> 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 >> > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 me at signpostmarv.name Mon May 18 14:52:27 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Mon, 18 May 2009 22:52:27 +0100 Subject: [sldev] New viewer name: Snowglobe In-Reply-To: <4A11D1FA.9030404@lindenlab.com> References: <4A11D1FA.9030404@lindenlab.com> Message-ID: <4A11D89B.2050704@signpostmarv.name> Suggestion for easter egg (need something newer than "Hippos!"): dragging the window about rapidly causes particle effects in the UI :-P ~ Marv. Philip Rosedale wrote: > Hey all, > > So 'Snowglobe' is the new name we picked for the new viewer we've all > been working on. Seemed clever (just think of the Citizen Kane > references), fun, referential to virtual worlds generally, and something > that could be effectively mutated for different projects (what you put > 'inside' the snowglobe). We've registered it and gotten some domains > (snowglobeproject.org, etc). Next step for us/LL is to come up with > some art, and flesh out some usage guidelines. > > So let's start updating the wiki(s) with the new name, and rebranding > patches also welcome (VWR-13295). Also any initial design ideas or > mockups for art would be great. We're trying to enlist some internal LL > folks for art treatments, but anything you want to throw in the ring is > welcome. > > Philip > > > > _______________________________________________ > 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/20090518/9946e2ad/attachment.bin From GordonWendt at gmail.com Mon May 18 15:10:21 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon, 18 May 2009 18:10:21 -0400 Subject: [sldev] New viewer name: Snowglobe In-Reply-To: <4A11D1FA.9030404@lindenlab.com> References: <4A11D1FA.9030404@lindenlab.com> Message-ID: <493033a70905181510s15683c60k985e4e290f052856@mail.gmail.com> Cool idea, is this just going to be a new viewer with just the rebranding changes or is this going to be a totally new generic viewer rewritten from the ground up? The latter would take a lot more work but I think would end up with better results. -Gordon On Mon, May 18, 2009 at 5:24 PM, Philip Rosedale wrote: > Hey all, > > So 'Snowglobe' is the new name we picked for the new viewer we've all > been working on. Seemed clever (just think of the Citizen Kane > references), fun, referential to virtual worlds generally, and something > that could be effectively mutated for different projects (what you put > 'inside' the snowglobe). We've registered it and gotten some domains > (snowglobeproject.org, etc). Next step for us/LL is to come up with > some art, and flesh out some usage guidelines. > > So let's start updating the wiki(s) with the new name, and rebranding > patches also welcome (VWR-13295). Also any initial design ideas or > mockups for art would be great. We're trying to enlist some internal LL > folks for art treatments, but anything you want to throw in the ring is > welcome. > > Philip > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090518/63e56a69/attachment.htm From foxsanyosuke at gmail.com Mon May 18 15:15:00 2009 From: foxsanyosuke at gmail.com (=?ISO-8859-1?Q?FoxSan_Yosuk=E9?=) Date: Tue, 19 May 2009 00:15:00 +0200 Subject: [sldev] New viewer name: Snowglobe In-Reply-To: <493033a70905181510s15683c60k985e4e290f052856@mail.gmail.com> References: <4A11D1FA.9030404@lindenlab.com> <493033a70905181510s15683c60k985e4e290f052856@mail.gmail.com> Message-ID: That's what I'm curious about too! o: Good to see progress, though I will not shake my screen when I start using the Snowglobe viewer xD With kind regards, FoxSan Yosuk? 2009/5/19 Gordon Wendt > Cool idea, is this just going to be a new viewer with just the rebranding > changes or is this going to be a totally new generic viewer rewritten from > the ground up? The latter would take a lot more work but I think would end > up with better results. > > -Gordon > > > On Mon, May 18, 2009 at 5:24 PM, Philip Rosedale wrote: > >> Hey all, >> >> So 'Snowglobe' is the new name we picked for the new viewer we've all >> been working on. Seemed clever (just think of the Citizen Kane >> references), fun, referential to virtual worlds generally, and something >> that could be effectively mutated for different projects (what you put >> 'inside' the snowglobe). We've registered it and gotten some domains >> (snowglobeproject.org, etc). Next step for us/LL is to come up with >> some art, and flesh out some usage guidelines. >> >> So let's start updating the wiki(s) with the new name, and rebranding >> patches also welcome (VWR-13295). Also any initial design ideas or >> mockups for art would be great. We're trying to enlist some internal LL >> folks for art treatments, but anything you want to throw in the ring is >> welcome. >> >> Philip >> > > > _______________________________________________ > 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/20090519/24da2ce6/attachment-0001.htm From melinda at superliminal.com Mon May 18 16:19:38 2009 From: melinda at superliminal.com (Melinda Green) Date: Mon, 18 May 2009 16:19:38 -0700 Subject: [sldev] New viewer name: Snowglobe In-Reply-To: <4A11D89B.2050704@signpostmarv.name> References: <4A11D1FA.9030404@lindenlab.com> <4A11D89B.2050704@signpostmarv.name> Message-ID: <4A11ED0A.9090803@superliminal.com> I love that suggestion!!! I was trying to think about similar ideas involving inertial sensors and other ways to trigger a snow effect but I think that SignpostMarv has the best idea for the perfect Easter egg. It must be done. -Melinda SignpostMarv Martin wrote: > Suggestion for easter egg (need something newer than "Hippos!"): > > dragging the window about rapidly causes particle effects in the UI :-P > > > ~ Marv. > > Philip Rosedale wrote: >> Hey all, >> >> So 'Snowglobe' is the new name we picked for the new viewer we've all >> been working on. Seemed clever (just think of the Citizen Kane >> references), fun, referential to virtual worlds generally, and >> something that could be effectively mutated for different projects >> (what you put 'inside' the snowglobe). We've registered it and >> gotten some domains (snowglobeproject.org, etc). Next step for >> us/LL is to come up with some art, and flesh out some usage guidelines. >> So let's start updating the wiki(s) with the new name, and rebranding >> patches also welcome (VWR-13295). Also any initial design ideas or >> mockups for art would be great. We're trying to enlist some internal >> LL folks for art treatments, but anything you want to throw in the >> ring is welcome. >> Philip From mrfrans at gmail.com Mon May 18 16:56:03 2009 From: mrfrans at gmail.com (Frans) Date: Tue, 19 May 2009 01:56:03 +0200 Subject: [sldev] New viewer name: Snowglobe In-Reply-To: <493033a70905181510s15683c60k985e4e290f052856@mail.gmail.com> References: <4A11D1FA.9030404@lindenlab.com> <493033a70905181510s15683c60k985e4e290f052856@mail.gmail.com> Message-ID: <7765f2c60905181656g68a71254s3ccd3fb98d7e9528@mail.gmail.com> This the new name for the http-texture branch or SLDev viewer. Which means the viewer will not be rewritten from the ground up, but continues as it has been the last 2 months. More info: https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts http://wiki.secondlife.com/wiki/Open_Source_Portal http://wiki.secondlife.com/wiki/Snowglobe On Tue, May 19, 2009 at 12:10 AM, Gordon Wendt wrote: > Cool idea, is this just going to be a new viewer with just the rebranding > changes or is this going to be a totally new generic viewer rewritten from > the ground up? The latter would take a lot more work but I think would end > up with better results. > > -Gordon > > -- Jeroen Frans Virtual World Technology Specialist. TheVesuviusGroup.com SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090519/6186047e/attachment.htm From GordonWendt at gmail.com Mon May 18 17:04:17 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon, 18 May 2009 20:04:17 -0400 Subject: [sldev] New viewer name: Snowglobe In-Reply-To: <7765f2c60905181656g68a71254s3ccd3fb98d7e9528@mail.gmail.com> References: <4A11D1FA.9030404@lindenlab.com> <493033a70905181510s15683c60k985e4e290f052856@mail.gmail.com> <7765f2c60905181656g68a71254s3ccd3fb98d7e9528@mail.gmail.com> Message-ID: <493033a70905181704v1aac257bs2d0f225a4a74edb7@mail.gmail.com> Oh good then. That means that it'll be essentially the same code base ths' in the current OSS alpha builds I think. -Gordon Wendt On Mon, May 18, 2009 at 7:56 PM, Frans wrote: > This the new name for the http-texture branch or SLDev viewer. Which means > the viewer will not be rewritten from the ground up, but continues as it has > been the last 2 months. > More info: > > https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts > http://wiki.secondlife.com/wiki/Open_Source_Portal > > http://wiki.secondlife.com/wiki/Snowglobe > > > On Tue, May 19, 2009 at 12:10 AM, Gordon Wendt wrote: > >> Cool idea, is this just going to be a new viewer with just the rebranding >> changes or is this going to be a totally new generic viewer rewritten from >> the ground up? The latter would take a lot more work but I think would end >> up with better results. >> >> -Gordon >> >> > -- > Jeroen Frans > Virtual World Technology Specialist. > TheVesuviusGroup.com > SL: Frans Charming > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090518/23672cf9/attachment.htm From missannotoole at yahoo.com Mon May 18 17:37:57 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Mon, 18 May 2009 17:37:57 -0700 (PDT) Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: References: <4A0F5CE5.2090307@gmail.com><4A0FA697.2050706@gmail.com><4A107003.1030808@boroon.dasgupta.ch><8 24c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com><9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com><2009051 8211130.04e51ce9.sldev@free.fr> <4A11BF17.8060002@lindenlab.com><32FB96532FEA4888BBA7C72FBD038442@slsystemspc> <4A11C79C.8070604@streamsense.net> Message-ID: <133154.9372.qm@web59104.mail.re1.yahoo.com> A lot of angry people today. (I don't recall how but for some reason I have known better than to take over 1000 items in a collection for more than a year.) One thing about this topic is that the future attachment memory pool limitations may severely impact certain types of attachments such as scanners. I have a scanner I love but am having to not use it anymore because it is part of the problem of sim performance using 0.8 milliseconds. I wonder how much memory it is eating. I am all in favor of reducing the impact of data collectors that facilitate research and security as soon as possible. As for the security aspect that drives a lot of scanner use cases I would like to be able to set, on the estate panel, a vertical limit on map teleporting. That way I can construct a simple barrier to flight at that level and have a secure sky studio zone. I.e.; set vertical map teleport limit to 2000 meters and construct a non sittable barrier above that level. They won't be able to see or get to what is at 4000 meters that way. That would reduce the need for so many script heavy orbs in huge cube matrices in sims to keep the rippers away from work in progress. (as well as the odd occasional lothario that shows up offering male escort services while I am working and subsequently wondering why orbs seem to be unreliable now) :P Just a thought. ________________________________ From: Kent Quirk (Q Linden) To: Thomas Grimshaw Cc: Second Life Developer Mailing List Sent: Monday, May 18, 2009 4:50:09 PM Subject: Re: [sldev] A thought on how to lower resources used by sensors Ya know, I'm all for creative discussion, and certainly there's plenty of criticism to go around. But I've seen an increase in ad hominem attacks. In this particular case, I'm betting that the person who coded the restriction was not an idiot (and no, I don't know who it was), nor do I think it's all that obvious that the decision was even a poor one. We may be learning that in practice the restriction causes more problems than it solves, but it would make it a lot easier for those of us at Linden to have intelligent conversations if the people we're conversing with were at least trying to be polite. Q -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090518/5b6b4437/attachment.htm From missannotoole at yahoo.com Mon May 18 17:44:06 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Mon, 18 May 2009 17:44:06 -0700 (PDT) Subject: [sldev] New viewer name: Snowglobe In-Reply-To: <4A11D1FA.9030404@lindenlab.com> References: <4A11D1FA.9030404@lindenlab.com> Message-ID: <716016.42576.qm@web59102.mail.re1.yahoo.com> So if we shake it real hard does it make it prettier? What sort of art is needed. I can help with that part. What happened to the big spaceship deal? Speaking of which I saw a screenshot somewhere on the SL blog supposedly of a linden and the avatar looked like a cardboard cutout. I hope it was just a bad video card and not some new version rofl. And if building a new UI then I would love to see user configurable toolbars so we can customize according to what we are doing at any given time. Sort of like how UIs work in other more "gameish" places. ________________________________ From: Philip Rosedale To: Second Life Developer Mailing List Sent: Monday, May 18, 2009 5:24:10 PM Subject: [sldev] New viewer name: Snowglobe Hey all, So 'Snowglobe' is the new name we picked for the new viewer we've all been working on. Seemed clever (just think of the Citizen Kane references), fun, referential to virtual worlds generally, and something that could be effectively mutated for different projects (what you put 'inside' the snowglobe). We've registered it and gotten some domains (snowglobeproject.org, etc). Next step for us/LL is to come up with some art, and flesh out some usage guidelines. So let's start updating the wiki(s) with the new name, and rebranding patches also welcome (VWR-13295). Also any initial design ideas or mockups for art would be great. We're trying to enlist some internal LL folks for art treatments, but anything you want to throw in the ring is welcome. Philip _______________________________________________ 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/20090518/68a6ff27/attachment.htm From aimee.trescothick at gmail.com Mon May 18 18:12:01 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Tue, 19 May 2009 02:12:01 +0100 Subject: [sldev] New viewer name: Snowglobe In-Reply-To: <716016.42576.qm@web59102.mail.re1.yahoo.com> References: <4A11D1FA.9030404@lindenlab.com> <716016.42576.qm@web59102.mail.re1.yahoo.com> Message-ID: <879A0A31-A83C-4D47-B324-805A9946C54A@gmail.com> On 19 May 2009, at 01:44, Ann Otoole wrote: > So if we shake it real hard does it make it prettier? Just don't shake too hard or you might induce a Snow Crash for those of us that are inside it ;) Aimee. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090519/b5c7d81c/attachment-0001.htm From tammynowotny at mac.com Mon May 18 18:22:07 2009 From: tammynowotny at mac.com (Tammy Nowotny) Date: Mon, 18 May 2009 21:22:07 -0400 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <4A11C79C.8070604@streamsense.net> References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> <4A107003.1030808@boroon.dasgupta.ch> <824c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com> <9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com> <20090518211130.04e51ce9.sldev@free.fr> <4A11BF17.8060002@lindenlab.com> <32FB96532FEA4888BBA7C72FBD038442@slsystemspc> <4A11C79C.8070604@streamsense.net> Message-ID: <70002540559615313654477985370037893728-Webmail@me.com> On Monday, May 18, 2009, at 04:39PM, "Thomas Grimshaw" wrote: >The probes can only uperate at up to 4,096m and can scan 96m higher than >that.. > >But the point is still absolutely valid. It's already perfectly easy and >possible to scan an entire sim, and everyone I know has a radar which >does this. > > I have one of those radars and it is not very accurate. It always misses avis whom I know are in fact on the sim. It wd be better if the sim just told the client directly who the avis are on the sim. (There are privacy issues, but hey! that's what alts and private estates are for!) --Tammy Nowotny From tigrospottystripes at gmail.com Mon May 18 18:28:38 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 18 May 2009 22:28:38 -0300 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <70002540559615313654477985370037893728-Webmail@me.com> References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> <4A107003.1030808@boroon.dasgupta.ch> <824c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com> <9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com> <20090518211130.04e51ce9.sldev@free.fr> <4A11BF17.8060002@lindenlab.com> <32FB96532FEA4888BBA7C72FBD038442@slsystemspc> <4A11C79C.8070604@streamsense.net> <70002540559615313654477985370037893728-Webmail@me.com> Message-ID: <4A120B46.50503@Gmail.com> Tammy Nowotny escreveu: > > On Monday, May 18, 2009, at 04:39PM, "Thomas Grimshaw" wrote: > >> The probes can only uperate at up to 4,096m and can scan 96m higher than >> that.. >> >> But the point is still absolutely valid. It's already perfectly easy and >> possible to scan an entire sim, and everyone I know has a radar which >> does this. >> >> >> > > I have one of those radars and it is not very accurate. It always misses avis whom I know are in fact on the sim. It wd be better if the sim just told the client directly who the avis are on the sim. (There are privacy issues, but hey! that's what alts and private estates are for!) > > --Tammy Nowotny > as far as I know the sim already does, the oficial client just doesn't5 make it obvious to the user, I remember seeing a jira entry that I think was about to be added to Snowglobe (wasn't called like that at the time) that would add hovertips for the dots on the minimap showing the name of the avatars, I'm not sure what happened to it, also, I believe there is a third-party client that has a builtin AV radar that uses that info, I can't remember which one it was though having said that, it would still be quite useful to have that data also avaiable to scripts, the sim already knows it, and keeps sending to all clients, why not make it avaiable to scripts as well? From aimee.trescothick at gmail.com Mon May 18 18:36:49 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Tue, 19 May 2009 02:36:49 +0100 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <4A120B46.50503@Gmail.com> References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> <4A107003.1030808@boroon.dasgupta.ch> <824c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com> <9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com> <20090518211130.04e51ce9.sldev@free.fr> <4A11BF17.8060002@lindenlab.com> <32FB96532FEA4888BBA7C72FBD038442@slsystemspc> <4A11C79C.8070604@streamsense.net> <70002540559615313654477985370037893728-Webmail@me.com> <4A120B46.50503@Gmail.com> Message-ID: <562619AD-200B-437D-808F-3FAA5354BCD2@gmail.com> On 19 May 2009, at 02:28, Tigro Spottystripes wrote: > as far as I know the sim already does, the oficial client just > doesn't > make it obvious to the user, I remember seeing a jira entry that I > think > was about to be added to Snowglobe (wasn't called like that at the > time) > that would add hovertips for the dots on the minimap showing the > name of > the avatars, I'm not sure what happened to it That's already in the 1.23 RC. Aimee. From chaosstar at gmail.com Mon May 18 23:39:23 2009 From: chaosstar at gmail.com (Ambrosia) Date: Tue, 19 May 2009 08:39:23 +0200 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <562619AD-200B-437D-808F-3FAA5354BCD2@gmail.com> References: <4A0F5CE5.2090307@gmail.com> <824c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com> <9bb32d430905180416v4338401el2cb1b9da5498d699@mail.gmail.com> <20090518211130.04e51ce9.sldev@free.fr> <4A11BF17.8060002@lindenlab.com> <32FB96532FEA4888BBA7C72FBD038442@slsystemspc> <4A11C79C.8070604@streamsense.net> <70002540559615313654477985370037893728-Webmail@me.com> <4A120B46.50503@Gmail.com> <562619AD-200B-437D-808F-3FAA5354BCD2@gmail.com> Message-ID: <9bb32d430905182339t204e2f23h1aa93a24d9dca7cd@mail.gmail.com> All in all I think, a function to return all avatar keys in the sim falls into the exact same category as the proposed functions to enhance llSetPos() with a new function that works in the whole rezspace: People already achieve those effects. With workarounds, client modifications, massive parallel scripting. The only difference between the current method, and the suggested functions for getting region avatar keys, for movement farther than 10m...is efficiency on the sim side. They are much, much better on sim resources. Anything else is already achieved by inefficient means in lots of commercial products, and I think anything that lowers the strain on sim resources these days is a blessing. Same reason why I personally am -aching- for functions like llSetLinkText, llLinkParticleSystem etc. The only reason some items are choc-full of scripts is because many operations are not possible on an object's links, forcing people to use -alot- more scripts than needed. Same category. Personally I think the focus of new LSL functions to come should be primarily on reducing the need for complex, repeptitive and/or massively parallel code/scripts. From carlo at alinoe.com Tue May 19 04:28:40 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 19 May 2009 13:28:40 +0200 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <4A11BF17.8060002@lindenlab.com> References: <20090518211130.04e51ce9.sldev@free.fr> <4A11BF17.8060002@lindenlab.com> Message-ID: <20090519112840.GA3561@alinoe.com> On Mon, May 18, 2009 at 01:03:35PM -0700, Kelly wrote: > difficulties that are less insurmountable but still trouble. By their nature > they are at least a little more load intensive than just accessing data the > region already has in memory would be. The problem of 'sensors' is that they do too many call backs to (cpu intensive) LSL scripts. Namely, whenever the distance to the sensor changes. The core of the problem here is that scripts are SLOW and for some reason use too much cpu (imho, I could write a server that can host the same at 1/10 of the cpu (and price)). For example, if sensor data wasn't needed for scripts but it would be sufficient to just have that data on the viewer, it wouldn't be a problem at all to include the coordinates of all avatars in a sim in a single packet and send that once a second to all viewers. Personally, I'd do this by default and provide the means to run HUD object scripts entirely client side (so that people can implement radars client side). [PS client side scripts should be open source, full permission] Unfortunately, as soon as you include any kind of limitation that can be overcome by using more than one sensor object, then that is what will be done. Therefore two things will be needed: 1) making things more efficient on the server, 2) limit resources per avatar/owner, and not per object. The latter will cause some people to start using secondary connections, but at least for a while that should be limited to only a hand full of hackers. PS. One way to limit sensors in a way that it can NOT be over come by using more than one sensor is by means of time and/or space quantisation that is the same for every object. For example you could only report coordinates (x,y) if z < 96 (and not at all if the sensor z > 50) modulo 4 meters. No matter how many sensors, one would never get more information than with one sensor. Unfortunately... that means that even for short distances the quantisation has to be same as for large distances and thus that llSensor() would have to be removed (because it would be a means to get MORE data by using it, still, in multiple objects). Hence that space quantisation can never be an option. Time quantisation could be in practise, but I'd really not like it when the normal llSensor suddenly starts to report changes only every 4 seconds. Now, if one would count the number of sensors in a region per owner and increase the time quantisation for all sensors per ratio than that would really be point 2 above. For example, at most four sensor() events per second per owner, at most one per second per script, and all calls quantisized at integer number of seconds UTC. The implementation of this would be easy (on the server) and require no viewer or protocol changes. The server would handle sensors once per second, keep a list of all sensors by owner in a priority queue where the priority depends on distance and time since last event, and only trigger the sensor() event for the first four. -- Carlo Wood From tateru.nino at gmail.com Tue May 19 05:30:43 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue, 19 May 2009 22:30:43 +1000 Subject: [sldev] New viewer name: Snowglobe In-Reply-To: <879A0A31-A83C-4D47-B324-805A9946C54A@gmail.com> References: <4A11D1FA.9030404@lindenlab.com> <716016.42576.qm@web59102.mail.re1.yahoo.com> <879A0A31-A83C-4D47-B324-805A9946C54A@gmail.com> Message-ID: <4A12A673.5020701@gmail.com> Aimee Trescothick wrote: > On 19 May 2009, at 01:44, Ann Otoole wrote: > >> So if we shake it real hard does it make it prettier? > > Just don't shake too hard or you might induce a Snow Crash for those > of us that are inside it ;) Let me just say here... 'argh' :) -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090519/255f4f0a/attachment.htm From monkowsk at watson.ibm.com Tue May 19 08:19:49 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue, 19 May 2009 11:19:49 -0400 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <20090519112840.GA3561@alinoe.com> References: <20090518211130.04e51ce9.sldev@free.fr> <4A11BF17.8060002@lindenlab.com> <20090519112840.GA3561@alinoe.com> Message-ID: <4A12CE15.3000900@watson.ibm.com> Carlo Wood wrote: > For example, if sensor data wasn't needed for scripts but > it would be sufficient to just have that data on the viewer, > it wouldn't be a problem at all to include the coordinates > of all avatars in a sim in a single packet and send that > once a second to all viewers. Personally, I'd do this by > default and provide the means to run HUD object scripts > entirely client side (so that people can implement radars > client side). [PS client side scripts should be open source, > full permission] That information is already sent to the viewer as CoarseLocationUpdate messages for use by the mini-map, but scripts only run on the sim. I am not familiar with the use of radar scripts. What do they do different from the mini-map? Mike From kerdezixe at gmail.com Tue May 19 08:21:59 2009 From: kerdezixe at gmail.com (Laurent Laborde) Date: Tue, 19 May 2009 17:21:59 +0200 Subject: [sldev] Linden Lab featured on datacenterknowledge.com Message-ID: <8a1bfe660905190821k6327be07w5042a47461b6675e@mail.gmail.com> Linden Lab will expand the back-end for its Second Life virtual world to the East Coast, adding server infrastructure at the NAP of the Capital Region, a large data center operated by Terremark Worldwide in Culpeper, Virginia. The colocation agreement will help Second Life extend its 3D virtual world environment to support additional users. Read more at : http://www.datacenterknowledge.com/archives/2009/05/18/second-life-adds-east-coast-servers/ Oh well... *sigh* Still not in Europe ... *whine* The bad latency (i have >200ms on SL sim from france, with a fiber optic line at home) is *really* a user experience killer :/ -- F4FQM Kerunix Flan Laurent Laborde From monkowsk at watson.ibm.com Tue May 19 08:26:58 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue, 19 May 2009 11:26:58 -0400 Subject: [sldev] New viewer name: Snowglobe In-Reply-To: <4A11D1FA.9030404@lindenlab.com> References: <4A11D1FA.9030404@lindenlab.com> Message-ID: <4A12CFC2.5080106@watson.ibm.com> Citizen Kane? Was he in Snow Crash? :-) > There is something new: A globe about the size of a grapefruit, a perfectly detailed rendition of Planet Earth, hanging in space at arm's length in front of his eyes. Hiro has heard about this but never seen it. It is a piece of CIC software called, simply, Earth. It is the user interface that CIC uses to keep track of every bit of spatial information that it owns - all the maps, weather data, architectural plans, and satellite surveillance stuff. Mike Philip Rosedale wrote: > Hey all, > > So 'Snowglobe' is the new name we picked for the new viewer we've all > been working on. Seemed clever (just think of the Citizen Kane > references), fun, referential to virtual worlds generally, and something > that could be effectively mutated for different projects (what you put > 'inside' the snowglobe). We've registered it and gotten some domains > (snowglobeproject.org, etc). Next step for us/LL is to come up with > some art, and flesh out some usage guidelines. From ordinal.malaprop at fastmail.fm Tue May 19 08:27:42 2009 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop at fastmail.fm) Date: Tue, 19 May 2009 16:27:42 +0100 Subject: [sldev] Linden Lab featured on datacenterknowledge.com In-Reply-To: <8a1bfe660905190821k6327be07w5042a47461b6675e@mail.gmail.com> References: <8a1bfe660905190821k6327be07w5042a47461b6675e@mail.gmail.com> Message-ID: <24FBD99B-A601-4F41-8668-1CB22CEAEDEE@fastmail.fm> Gradually getting closer, though. Didn't I hear something about a datacenter planned in the UK? Or was that wishful thinking on my part? On 19 May 2009, at 16:21, Laurent Laborde wrote: > Linden Lab will expand the back-end for its Second Life virtual world > to the East Coast, adding server infrastructure at the NAP of the > Capital Region, a large data center operated by Terremark Worldwide in > Culpeper, Virginia. The colocation agreement will help Second Life > extend its 3D virtual world environment to support additional users. > Read more at : http://www.datacenterknowledge.com/archives/2009/05/18/second-life-adds-east-coast-servers/ > > Oh well... *sigh* > Still not in Europe ... *whine* > > The bad latency (i have >200ms on SL sim from france, with a fiber > optic line at home) is *really* a user experience killer :/ > > -- > F4FQM > Kerunix Flan > Laurent Laborde > _______________________________________________ > 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 Tue May 19 08:29:45 2009 From: kelly at lindenlab.com (Kelly) Date: Tue, 19 May 2009 08:29:45 -0700 Subject: [sldev] Linden Lab featured on datacenterknowledge.com In-Reply-To: <8a1bfe660905190821k6327be07w5042a47461b6675e@mail.gmail.com> References: <8a1bfe660905190821k6327be07w5042a47461b6675e@mail.gmail.com> Message-ID: <4A12D069.8000309@lindenlab.com> Laurent Laborde wrote: > Linden Lab will expand the back-end for its Second Life virtual world > to the East Coast, adding server infrastructure at the NAP of the > Capital Region, a large data center operated by Terremark Worldwide in > Culpeper, Virginia. The colocation agreement will help Second Life > extend its 3D virtual world environment to support additional users. > Read more at : http://www.datacenterknowledge.com/archives/2009/05/18/second-life-adds-east-coast-servers/ > > Oh well... *sigh* > Still not in Europe ... *whine* > > The bad latency (i have >200ms on SL sim from france, with a fiber > optic line at home) is *really* a user experience killer :/ > > I can't speak to business decisions, however there are technical hurdles to overcome before we can handle the kind of latency you describe within our own infrastructure. There is a lot of communication that happens between hosts within our system - database access, asset system access, sim to sim communication just for starters. I agree 200ms pings suck, I'm totally with you. We even have offices in the UK, we know. It just isn't as simple as putting a few computers on that side of the ocean, unfortunately. As Ordinal says though, we are getting closer. :) /me keeps his fingers crossed. - Kelly From secret.argent at gmail.com Tue May 19 08:05:11 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 19 May 2009 10:05:11 -0500 Subject: [sldev] Hide geometry in Sculpted-prims In-Reply-To: References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> Message-ID: <5886673C-8E0B-4323-A3EF-E67C3A444F0B@gmail.com> On 2009-05-17, at 12:05, Dahlia Trimble wrote: > I've also seen a lot of designers use the alpha channel to mask the > entire bitmap so it doesn't show in the editor and can't be grabbed > with a screen capture That is why there is a flag proposed for indicating that alpha indicates flexibility. You will need to add a flag to the sculpt to indicate that some specific value means "not a point", and once you do that you can use <0,0,0> as easily as alpha since only new objects will be effected. From secret.argent at gmail.com Tue May 19 08:08:20 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 19 May 2009 10:08:20 -0500 Subject: [sldev] Hide geometry in Sculpted-prims In-Reply-To: References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> Message-ID: On 2009-05-17, at 17:53, Dale Mahalko wrote: > Expansion is needed for more 2D arrays and more data storage, but > this is going to break the ever so simple and clever concept of > sculpts as RGB maps. Probably because it is too simple and clever to > really be practical in the first place. The next step beyond sculpt maps is object upload, not more complex maps. Though if you want an image format with an arbitrary number of layers, that's what TGA is all about. From robla at lindenlab.com Tue May 19 09:28:32 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 19 May 2009 09:28:32 -0700 Subject: [sldev] Crash stats from the past week Message-ID: <4A12DE30.4090603@lindenlab.com> Hi everyone, Here's the crash stats from the past week: Second Life OSS 1.23.2.2283: 2009-05-19: 3 crashes from 1 agents 2009-05-18: 25 crashes from 6 agents 2009-05-17: 2 crashes from 1 agents Second Life OSS 1.23.2.2259: 2009-05-18: 1 crashes from 1 agents 2009-05-16: 3 crashes from 3 agents, 29.12 hours, 22 sessions, 6 agents 2009-05-15: 2 crashes from 2 agents, 19.98 hours, 35 sessions, 13 agents 2009-05-14: 5 crashes from 1 agents, 4.47 hours, 15 sessions, 6 agents Second Life OSS 1.23.0.2244: 2009-05-16: 0 crashes from 0 agents, 1.83 hours, 4 sessions, 4 agents 2009-05-15: 1 crashes from 1 agents, 1.68 hours, 3 sessions, 2 agents 2009-05-14: 1 crashes from 1 agents, 13.97 hours, 17 sessions, 9 agents 2009-05-13: 4 crashes from 3 agents, 15.10 hours, 27 sessions, 15 agents 2009-05-12: 6 crashes from 5 agents Second Life OSS 1.23.0.2235: 2009-05-16: 0 crashes from 0 agents, 0.12 hours, 1 sessions, 1 agents Second Life OSS 1.23.0.2232: 2009-05-14: 2 crashes from 1 agents, 0.77 hours, 2 sessions, 1 agents Second Life OSS 1.23.0.2166: 2009-05-15: 0 crashes from 0 agents, 0.07 hours, 1 sessions, 1 agents I've added the "from x agents" bit since the last report, since the raw number of crashes wasn't telling the whole story. Yesterday, resident Sheet Spotter was helping us out and crashing a LOT, so that was sending the numbers up a bit. I'm thinking about flipping the axes for the summary above, reverse sorting first by date, then by version (send me mail privately if you have an opinion about this, or file a JIRA task). Also, not many people have weighed in on where a daily cron job should point, but the ones that have seem to agree that sldev@ isn't the place. More discussion here: http://jira.secondlife.com/browse/VWR-13573 Based on what I've seen from the crash reports, they still reduce down to the following three bugs: "http-texture branch viewer locks up and client must be killed, no crash report is generated" http://jira.secondlife.com/browse/VWR-13437 "Occasional crashes in OpenJPEG" https://jira.secondlife.com/browse/VWR-13511 "Curl crashers" https://jira.secondlife.com/browse/VWR-12952 Any help you all can offer in narrowing down any of those three would be greatly appreciated. Rob From philip at lindenlab.com Tue May 19 10:34:44 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Tue, 19 May 2009 10:34:44 -0700 Subject: [sldev] New viewer name: Snowglobe In-Reply-To: <4A12CFC2.5080106@watson.ibm.com> References: <4A11D1FA.9030404@lindenlab.com> <4A12CFC2.5080106@watson.ibm.com> Message-ID: <4A12EDB4.5000100@lindenlab.com> I knew it was a great name! :) Actually, I forgot to mention that love for suggesting it goes to Q Linden, who suggested the name in a meeting we were having after hearing Merov laughingly say "Rosebud". Hence the Citizen Kane reference. P Mike Monkowski wrote: > Citizen Kane? Was he in Snow Crash? :-) >> There is something new: A globe about the size of a grapefruit, a >> perfectly detailed rendition of Planet Earth, hanging in space at >> arm's length in front of his eyes. Hiro has heard about this but >> never seen it. It is a piece of CIC software called, simply, Earth. >> It is the user interface that CIC uses to keep track of every bit of >> spatial information that it owns - all the maps, weather data, >> architectural plans, and satellite surveillance stuff. > > Mike > > Philip Rosedale wrote: >> Hey all, >> >> So 'Snowglobe' is the new name we picked for the new viewer we've all >> been working on. Seemed clever (just think of the Citizen Kane >> references), fun, referential to virtual worlds generally, and >> something that could be effectively mutated for different projects >> (what you put 'inside' the snowglobe). We've registered it and >> gotten some domains (snowglobeproject.org, etc). Next step for >> us/LL is to come up with some art, and flesh out some usage guidelines. From jhurliman at jhurliman.org Tue May 19 11:08:19 2009 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue, 19 May 2009 11:08:19 -0700 Subject: [sldev] Hide geometry in Sculpted-prims In-Reply-To: References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> Message-ID: JPEG2000 supports an arbitrary number of channels/layers/whatever you want to call them. In fact, avatar bakes are five channels (the last two are used for bump-mapping and something else). I agree though that you start to get diminishing returns from sculpties pretty quickly. Take a 128x128 five layer sculpty vs. a decently robust format built on top of a progressive meshing algorithm ( http://research.microsoft.com/en-us/um/people/hoppe/pm.pdf) and compare the vertices per second, error curves, and total download sizes. John On Tue, May 19, 2009 at 8:08 AM, Argent Stonecutter wrote: > On 2009-05-17, at 17:53, Dale Mahalko wrote: > > Expansion is needed for more 2D arrays and more data storage, but > > this is going to break the ever so simple and clever concept of > > sculpts as RGB maps. Probably because it is too simple and clever to > > really be practical in the first place. > > The next step beyond sculpt maps is object upload, not more complex > maps. > > Though if you want an image format with an arbitrary number of layers, > that's what TGA is all about. > > _______________________________________________ > 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/20090519/101c5863/attachment.htm From jhurliman at jhurliman.org Tue May 19 11:15:01 2009 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue, 19 May 2009 11:15:01 -0700 Subject: [sldev] Client-side limitations when rendering lots of avatars? Message-ID: Are there any hard-coded values or other settings in the viewer that would prevent it from rendering a lot (three to four digit range) of avatars on the screen at once? There's no reason an upper end machine with dual SLI nVidia 8800GTX (768MB) cards and 4GB of system memory should balk at drawing 1000 of the same mesh on the screen at once in a basic scene. What are the relevant settings to tweak with? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090519/d9f82c25/attachment.htm From teravus at gmail.com Tue May 19 11:24:04 2009 From: teravus at gmail.com (Teravus Ovares) Date: Tue, 19 May 2009 14:24:04 -0400 Subject: [sldev] Client-side limitations when rendering lots of avatars? In-Reply-To: References: Message-ID: <34cc66250905191124h40fdab4dl2756af24eb87dc89@mail.gmail.com> In the debug settings, it's RenderAvatarMaxVisible. Yes, there's a default limit of 35. Regards Teravus On 5/19/09, John Hurliman wrote: > Are there any hard-coded values or other settings in the viewer that would > prevent it from rendering a lot (three to four digit range) of avatars on > the screen at once? There's no reason an upper end machine with dual SLI > nVidia 8800GTX (768MB) cards and 4GB of system memory should balk at drawing > 1000 of the same mesh on the screen at once in a basic scene. What are the > relevant settings to tweak with? > > John > > _______________________________________________ > 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 jhurliman at jhurliman.org Tue May 19 11:15:01 2009 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue, 19 May 2009 11:15:01 -0700 Subject: [sldev] Client-side limitations when rendering lots of avatars? Message-ID: Are there any hard-coded values or other settings in the viewer that would prevent it from rendering a lot (three to four digit range) of avatars on the screen at once? There's no reason an upper end machine with dual SLI nVidia 8800GTX (768MB) cards and 4GB of system memory should balk at drawing 1000 of the same mesh on the screen at once in a basic scene. What are the relevant settings to tweak with? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090519/d9f82c25/attachment-0003.htm From dahliatrimble at gmail.com Tue May 19 11:41:36 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue, 19 May 2009 11:41:36 -0700 Subject: [sldev] Client-side limitations when rendering lots of avatars? In-Reply-To: References: Message-ID: Are they really the same mesh? most have different levels of morphs applied for shape variation, many have prim accessories, and they may be running different animations. They also have varied textures. I suspect these may be some of the limiting factors. On Tue, May 19, 2009 at 11:15 AM, John Hurliman wrote: > Are there any hard-coded values or other settings in the viewer that would > prevent it from rendering a lot (three to four digit range) of avatars on > the screen at once? There's no reason an upper end machine with dual SLI > nVidia 8800GTX (768MB) cards and 4GB of system memory should balk at drawing > 1000 of the same mesh on the screen at once in a basic scene. What are the > relevant settings to tweak with? > > John > > _______________________________________________ > 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/20090519/7e1aba0b/attachment.htm From jhurliman at jhurliman.org Tue May 19 11:47:31 2009 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue, 19 May 2009 11:47:31 -0700 Subject: [sldev] Client-side limitations when rendering lots of avatars? In-Reply-To: References: Message-ID: These avatars have no attachments and are all wearing the same outfit, although I'm pretty sure that will still turn into separate texture bakes for every one. Even 1000 unique meshes should be in the realm of modern visual computing ability. John On Tue, May 19, 2009 at 11:41 AM, Dahlia Trimble wrote: > Are they really the same mesh? most have different levels of morphs applied > for shape variation, many have prim accessories, and they may be running > different animations. They also have varied textures. I suspect these may be > some of the limiting factors. > > On Tue, May 19, 2009 at 11:15 AM, John Hurliman wrote: > >> Are there any hard-coded values or other settings in the viewer that would >> prevent it from rendering a lot (three to four digit range) of avatars on >> the screen at once? There's no reason an upper end machine with dual SLI >> nVidia 8800GTX (768MB) cards and 4GB of system memory should balk at drawing >> 1000 of the same mesh on the screen at once in a basic scene. What are the >> relevant settings to tweak with? >> >> John >> >> _______________________________________________ >> 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/20090519/1512d9ee/attachment.htm From jan.ciger at gmail.com Tue May 19 13:02:13 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Tue, 19 May 2009 22:02:13 +0200 Subject: [sldev] Client-side limitations when rendering lots of avatars? In-Reply-To: References: Message-ID: <4A131045.2040307@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Hurliman wrote: > These avatars have no attachments and are all wearing the same outfit, > although I'm pretty sure that will still turn into separate texture > bakes for every one. Even 1000 unique meshes should be in the realm of > modern visual computing ability. It is - I did 10 000 once. However, that was with custom code, not SL, but on an ancient GeForce 4 or so - some 6 years ago. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKExBCn11XseNj94gRAiEzAKDgpfda3L3CkcgNuMVxjK+O/vFvPwCgu0cR wTZAESRV8SYoniW6fZlMu3Y= =SBnm -----END PGP SIGNATURE----- From teravus at gmail.com Tue May 19 13:15:10 2009 From: teravus at gmail.com (Teravus Ovares) Date: Tue, 19 May 2009 16:15:10 -0400 Subject: [sldev] Client-side limitations when rendering lots of avatars? In-Reply-To: <4A131045.2040307@gmail.com> References: <4A131045.2040307@gmail.com> Message-ID: <34cc66250905191315m7edcdd18x8dafaa2383d29dd5@mail.gmail.com> I had it at 110 a few years ago when Daryth Kennedy was doing limited edition dragon avatar releases on the 'first buy, first get' system. The sim that hosted the vendors would fill up to 105 avatar for an hour or so before the event(Yes, the sim count would say somewhere between 100 and 105 root agents in sim stats). It *does* bring both the simulator system, and the client system to it's knees. Takes great screen shots though assuming that you save them to your hard drive and upload them later. (upload to inventory frequently fails under that strain) Regards Teravus On 5/19/09, Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > John Hurliman wrote: > > These avatars have no attachments and are all wearing the same outfit, > > although I'm pretty sure that will still turn into separate texture > > bakes for every one. Even 1000 unique meshes should be in the realm of > > modern visual computing ability. > > It is - I did 10 000 once. However, that was with custom code, not SL, > but on an ancient GeForce 4 or so - some 6 years ago. > > Regards, > > Jan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFKExBCn11XseNj94gRAiEzAKDgpfda3L3CkcgNuMVxjK+O/vFvPwCgu0cR > wTZAESRV8SYoniW6fZlMu3Y= > =SBnm > -----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 > From merov at lindenlab.com Tue May 19 14:51:42 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Tue, 19 May 2009 14:51:42 -0700 Subject: [sldev] VWR-10311 : Lip Sync enabling patch Message-ID: <266514F2-81B7-4688-8B2D-3C4FA6FE088E@lindenlab.com> Hi guys, I reviewed Mike's patches and tweaked a little: - suppressed the Advanced menu item - added French l10n I attached a new patch to VWR-10311 covering both VWR-10311 and VWR-13260. Mike, review appreciated :) Cheers, - Merov From robla at lindenlab.com Tue May 19 14:56:03 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 19 May 2009 14:56:03 -0700 Subject: [sldev] A "SNOW" project in JIRA? Message-ID: <4A132AF3.1000700@lindenlab.com> Hi folks, One thing that we're grappling with right now is the fact that when we want to mark something "resolved" in Snowglobe, everyone needs a way to keep track of if/when something will make it into the main Second Life viewer. Being "resolved" in Snowglobe is independent of being "resolved" in the Second Life viewer. There are several ways of fixing this problem: 1. Treat Snowglobe as a separate project from the "VWR" (Second Life Viewer) project, creating a "SNOW" project. Have duplicate issues in each for problem reports that affect both. PROS: keeps things cleanly separated. Lets us use the "roadmap" features for SNOW independently of VWR issues CONS: Busywork of duplicating issues 2. Create a custom field for "Resolved in Snowglobe" PROS: keeps everything in one tidy place. Less busywork. CONS: makes it really easy for the people working on Snowglobe to get confused about what's open/closed in Snowglobe. Query options are limited 3. Create new states for "Resolved in Snowglobe", "Resolved in Second Life Viewer" PROS: sounds good on the surface CONS: combinatorial nightmare. This one is pretty much a non-starter, but I'm including it here because it seems this is where many folks want to go when they're first asked. I've filed the issue here: http://jira.secondlife.com/browse/WEB-1118 Please let me know what you think in JIRA. Thanks Rob From alissa_sabre at yahoo.co.jp Tue May 19 03:11:49 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue, 19 May 2009 19:11:49 +0900 Subject: [sldev] New viewer name: Snowglobe In-Reply-To: <4A11D1FA.9030404@lindenlab.com> References: <4A11D1FA.9030404@lindenlab.com> Message-ID: <1f74dz4ds46ox1kQtP6cQr9.alissa_sabre@yahoo.co.jp> > So 'Snowglobe' is the new name we picked for the new viewer we've all > been working on. Ah, may I ask which viewer you decided to call 'Snowglobe' exactly? As Philip seems to concentrate on http-texture branch, I assume you decided to replace the word 'http-texture' with 'Snowglobe', but a new domain name and new art? > So let's start updating the wiki(s) with the new name I have a feeling that we need complete understanding on what is Snowglobe and what is not before editing wiki pages... Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From robla at lindenlab.com Tue May 19 15:26:33 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 19 May 2009 15:26:33 -0700 Subject: [sldev] New viewer name: Snowglobe In-Reply-To: <1f74dz4ds46ox1kQtP6cQr9.alissa_sabre@yahoo.co.jp> References: <4A11D1FA.9030404@lindenlab.com> <1f74dz4ds46ox1kQtP6cQr9.alissa_sabre@yahoo.co.jp> Message-ID: <4A133219.3070101@lindenlab.com> On 05/19/2009 03:11 AM, Alissa Sabre wrote: >> So 'Snowglobe' is the new name we picked for the new viewer we've all >> been working on. >> > > Ah, may I ask which viewer you decided to call 'Snowglobe' exactly? > > As Philip seems to concentrate on http-texture branch, I assume you > decided to replace the word 'http-texture' with 'Snowglobe', but > a new domain name and new art? > New art at a minimum. We have domain names set up that we'll probably crank up at some point. >> So let's start updating the wiki(s) with the new name >> > > I have a feeling that we need complete understanding on what is > Snowglobe and what is not before editing wiki pages... > I've started the process here: https://wiki.secondlife.com/wiki/Snowglobe Rob From melinda at superliminal.com Tue May 19 15:45:43 2009 From: melinda at superliminal.com (Melinda Green) Date: Tue, 19 May 2009 15:45:43 -0700 Subject: [sldev] New viewer name: Snowglobe In-Reply-To: <1f74dz4ds46ox1kQtP6cQr9.alissa_sabre@yahoo.co.jp> References: <4A11D1FA.9030404@lindenlab.com> <1f74dz4ds46ox1kQtP6cQr9.alissa_sabre@yahoo.co.jp> Message-ID: <4A133697.40104@superliminal.com> Ah ha, great question, Alissa! I totally agree that we need to be clear with our names and terminology. I've already made some small wiki edits using my own understanding in mind so I'll just spell out my understanding and encourage others to jump in if they have a different understanding. * Snowglobe is the name of the *product* regardless of when any binary is built from the associated branch. * HTTP-texture is the name of the first major *project* going into the product, as well as being the name of the branch (presumably soon to be renamed). There is no need to use the phrase "Snowglobe viewer" any more than you would use the phrase "Firefox browser". I would say things like "Snowglobe uses HTTP textures" the same way I would say "Firefox has a plug-in architecture". The longer form is accurate, but I think it is especially helpful to use the shorter term when possible especially because I think the term "viewer" was poorly chosen and we should stop using it when describing all Second Life clients. Each product line should have it's own unique name. I'm *really* glad that this one has been named. And such a cute name it is! Thanks Q! -Melinda Alissa Sabre wrote: >> So 'Snowglobe' is the new name we picked for the new viewer we've all >> been working on. >> > > Ah, may I ask which viewer you decided to call 'Snowglobe' exactly? > > As Philip seems to concentrate on http-texture branch, I assume you > decided to replace the word 'http-texture' with 'Snowglobe', but > a new domain name and new art? > > >> So let's start updating the wiki(s) with the new name >> > > I have a feeling that we need complete understanding on what is > Snowglobe and what is not before editing wiki pages... > > Alissa Sabre > > From aimee.trescothick at gmail.com Tue May 19 15:49:24 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Tue, 19 May 2009 23:49:24 +0100 Subject: [sldev] [Patch] VWR-6918 Tools menu option to hide selection outlines In-Reply-To: <80E59499-B3E3-4EF4-BDEA-CB746FAAC1E1@gmail.com> References: <80E59499-B3E3-4EF4-BDEA-CB746FAAC1E1@gmail.com> Message-ID: <17C33B5F-F7ED-46DE-B0E8-7782DAEB3581@gmail.com> Anyone on the reviewer list out there that could give this patch a try so I can commit it? :) Aimee. On 14 May 2009, at 18:48, Aimee Trescothick wrote: > I have just attached a patch to VWR-6918 adding an option to the > tools menu which make it possible to hide the selection highlights > while building. This is of great use while using very small prims, > or aligning textures. > > The current work around (http://wiki.secondlife.com/wiki/Video_Tutorial/Turning_off_object_selection_glow > ) is extremely inconvenient involving changing the > SelectionHighlightThickness debug setting and relogging every time > you want to turn them on or off. Having a menu item to turn them on > or off means that they can be toggled on the fly without even losing > your current selection. > > I'd appreciate any feedback people may have, and if someone could > review the patch with a view to committing it to http-texture. > > Aimee. From dzonatas at gmail.com Tue May 19 16:56:21 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Tue, 19 May 2009 16:56:21 -0700 Subject: [sldev] Is 1.21+ version required because of difference in login procedure? Message-ID: <4A134725.1060101@gmail.com> I've asked this on IRC since yesterday, but I haven't got any response as of yet (over other active discussions). Besides obvious upgrade and cut-off reasons, will the May 21st requirement to upgrade include a procedural difference in login requirements? I ask because I don't know where to look to find out if the basic login procedure that exists now in the 1.22 viewer will continue to work or will weblogin-key and all the related newer changes be the only option after May 21st? I do not know if the talk months ago about procedural changes in the login process is completely rolled out or if there is still something left in a #ifdef somewhere that still matters for days like May 21st. Any response appreciated... 2 days left. From merov at lindenlab.com Tue May 19 17:56:31 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Tue, 19 May 2009 17:56:31 -0700 Subject: [sldev] VWR-10311 : Lip Sync enabling patch In-Reply-To: <266514F2-81B7-4688-8B2D-3C4FA6FE088E@lindenlab.com> References: <266514F2-81B7-4688-8B2D-3C4FA6FE088E@lindenlab.com> Message-ID: <5072AFC2-827E-47F1-B745-7E348A0E26C7@lindenlab.com> OK, after one last round of checks by Mike, I committed this under svn rev 2291. Thanks Mike! :) Cheers, - Merov On May 19, 2009, at 2:51 PM, Philippe Bossut (Merov Linden) wrote: > Hi guys, > > I reviewed Mike's patches and tweaked a little: > - suppressed the Advanced menu item > - added French l10n > > I attached a new patch to VWR-10311 covering both VWR-10311 and > VWR-13260. > > Mike, review appreciated :) > > Cheers, > - Merov > _______________________________________________ > 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 jhurliman at jhurliman.org Tue May 19 18:20:46 2009 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue, 19 May 2009 18:20:46 -0700 Subject: [sldev] Is 1.21+ version required because of difference in login procedure? In-Reply-To: <4A134725.1060101@gmail.com> References: <4A134725.1060101@gmail.com> Message-ID: web_login_key doesn't appear to work in any of the current viewer binaries or SVN trunk. As I understand it, web_login_key is only working in the Meerkat project after they patched the code to fix it. John On Tue, May 19, 2009 at 4:56 PM, Dzonatas Sol wrote: > I've asked this on IRC since yesterday, but I haven't got any response > as of yet (over other active discussions). > > Besides obvious upgrade and cut-off reasons, will the May 21st > requirement to upgrade include a procedural difference in login > requirements? I ask because I don't know where to look to find out if > the basic login procedure that exists now in the 1.22 viewer will > continue to work or will weblogin-key and all the related newer changes > be the only option after May 21st? I do not know if the talk months ago > about procedural changes in the login process is completely rolled out > or if there is still something left in a #ifdef somewhere that still > matters for days like May 21st. > > Any response appreciated... 2 days left. > _______________________________________________ > 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/20090519/7e957ae9/attachment-0001.htm From jhurliman at jhurliman.org Tue May 19 18:22:45 2009 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue, 19 May 2009 18:22:45 -0700 Subject: [sldev] Passing in loginuri with secondlife:/// Message-ID: What is the URI format for secondlife:///app/login if I want to tell the viewer to login to a grid at ? I am looking at < http://wiki.secondlife.com/wiki/Viewer_URI_Name_Space> and it nothing is jumping out at me. John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090519/3d3ce380/attachment.htm From dynaturtle.cai at gmail.com Tue May 19 18:25:43 2009 From: dynaturtle.cai at gmail.com (Cai Xiao(dynaturtle)) Date: Wed, 20 May 2009 09:25:43 +0800 Subject: [sldev] How to make speicific cyclinder Message-ID: <448f7bd20905191825t7a81ef3fudfcce67ad7c772fa@mail.gmail.com> Hello, guys! I want to make cylinder whose bottom is arbitrary polygon using sculpt texture. My idea is quite simple, just triangulate the cylinder in order to get a triangles mesh. Then represent the mesh using sculpt texture. But the result didn't meet my expect. I am not sure what is wrong with it. Does anyone ever do relevant thing? And would you share some experience with me? Thanks in advance! -- Department of Spatial Information Science&Technology, School of Earth&Space Science, Peking University ADD: Room 3028, Building 46, Peking University, Beijing, P.R. China Zip Code: 100871 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090520/4a6f9216/attachment.htm From feilen1000 at gmail.com Tue May 19 17:16:42 2009 From: feilen1000 at gmail.com (Feilen) Date: Tue, 19 May 2009 19:16:42 -0500 Subject: [sldev] Hide geometry in Sculpted-prims Message-ID: <4A134BEA.8060105@gmail.com> Argent Stonecutter wrote: > On 2009-05-17, at 17:53, Dale Mahalko wrote: > >> > Expansion is needed for more 2D arrays and more data storage, but >> > this is going to break the ever so simple and clever concept of >> > sculpts as RGB maps. Probably because it is too simple and clever to >> > really be practical in the first place. >> > > The next step beyond sculpt maps is object upload, not more complex > maps. > > Though if you want an image format with an arbitrary number of layers, > that's what TGA is all about. > I'm all for full mesh uploads, but for some reason the idea of such seems to be seen negatively. The original idea of a sculptie was for an organic object that was dynamically renderable by the SL viewer. However, when people complained about distortions, the "Lossless Quality" option was added that would make them appear the same as the original sculpt, mostly defeating the purpose. I think the best idea for the alpha channel would be a drop-down menu for what the purpose of it is. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090519/402245d8/attachment.htm From melinda at superliminal.com Tue May 19 19:34:34 2009 From: melinda at superliminal.com (Melinda Green) Date: Tue, 19 May 2009 19:34:34 -0700 Subject: [sldev] How to make speicific cyclinder In-Reply-To: <448f7bd20905191825t7a81ef3fudfcce67ad7c772fa@mail.gmail.com> References: <448f7bd20905191825t7a81ef3fudfcce67ad7c772fa@mail.gmail.com> Message-ID: <4A136C3A.3090802@superliminal.com> Why do you want to do that when SL already supports cylinder primitives? I hope you do not want to implement individual polygons using sculpties. Proper polygon mesh primitives are definitely coming so it may be best to wait for that if you can. -Melinda Cai Xiao(dynaturtle) wrote: > Hello, guys! > I want to make cylinder whose bottom is arbitrary polygon using sculpt > texture. My idea is quite simple, just triangulate the cylinder in > order to get a triangles mesh. Then represent the mesh using sculpt > texture. But the result didn't meet my expect. I am not sure what is > wrong with it. Does anyone ever do relevant thing? And would you share > some experience with me? Thanks in advance! > > -- > Department of Spatial Information Science&Technology, > School of Earth&Space Science, Peking University > From sheet.spotter at gmail.com Tue May 19 21:33:05 2009 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Tue, 19 May 2009 23:33:05 -0500 Subject: [sldev] HTTP-texture documentation Message-ID: <008DCEB4990C48B3B0EB301124E1C88D@kenb> Would the attached class diagram be a welcome addition to the description of threads on the HTTP Texture wiki page? http://wiki.secondlife.com/wiki/HTTP_Texture Images and diagrams can be helpful in getting up to speed on the architecture. Yet the wiki seems to have very few images and diagrams. The attached class diagram is still a work in progress. It's a dumbed-down version of the actual classes, only highlighting the relationship between the classes and highlighting key variables. It will only take another hour or two to complete the diagram. It should not change substantially from the attachment. If there's positive feedback, the completed diagram could be added in another day or two. Sheet Spotter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090519/53b8a767/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: ClassDiagram.png Type: image/png Size: 115791 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090519/53b8a767/attachment-0001.png From moriz.gupte at gmail.com Tue May 19 21:38:12 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Tue, 19 May 2009 22:38:12 -0600 Subject: [sldev] HTTP-texture documentation In-Reply-To: <008DCEB4990C48B3B0EB301124E1C88D@kenb> References: <008DCEB4990C48B3B0EB301124E1C88D@kenb> Message-ID: Hey sheet, I find this approach of presenting the architecture helpful (but this is personal of course). My vote is yes. R On Tue, May 19, 2009 at 10:33 PM, Sheet Spotter wrote: > Would the attached class diagram be a welcome addition to the description > of threads on the HTTP Texture wiki page? > > http://wiki.secondlife.com/wiki/HTTP_Texture > > > > Images and diagrams can be helpful in getting up to speed on the > architecture. Yet the wiki seems to have very few images and diagrams. > > > > The attached class diagram is still a work in progress. It?s a dumbed-down > version of the actual classes, only highlighting the relationship between > the classes and highlighting key variables. > > > > It will only take another hour or two to complete the diagram. It should > not change substantially from the attachment. > > > > If there?s positive feedback, the completed diagram could be added in > another day or two. > > > > > > 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 > -- Rameshsharma Ramloll PhD Research Assistant Professor Idaho State University, PocatelloTel: 208-282-5333 More info at http://tr.im/RRamloll -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090519/f9ff47bd/attachment.htm From stickman at gmail.com Tue May 19 21:53:48 2009 From: stickman at gmail.com (Stickman) Date: Tue, 19 May 2009 21:53:48 -0700 Subject: [sldev] How to make speicific cyclinder In-Reply-To: <4A136C3A.3090802@superliminal.com> References: <448f7bd20905191825t7a81ef3fudfcce67ad7c772fa@mail.gmail.com> <4A136C3A.3090802@superliminal.com> Message-ID: > Proper polygon mesh primitives are definitely coming so it may be best > to wait for that if you can. I haven't heard ANYTHING about this, and I am very interested in it. The few Jiras I've seen on the issue were so woefully lacking on information that I feared to vote for them because there's no telling what could get put in. I've been looking for time to build up a more complete Jira on the issue of mesh primitives -- and riggable meshes. May I ask where you got this information, and if it's a source I can peruse? Thank you, Stickman From missannotoole at yahoo.com Tue May 19 22:13:07 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Tue, 19 May 2009 22:13:07 -0700 (PDT) Subject: [sldev] How to make speicific cyclinder In-Reply-To: <4A136C3A.3090802@superliminal.com> References: <448f7bd20905191825t7a81ef3fudfcce67ad7c772fa@mail.gmail.com> <4A136C3A.3090802@superliminal.com> Message-ID: <624162.53102.qm@web59102.mail.re1.yahoo.com> Please show proof of this claim LL is going to implement obj uploads. Exact proof please. No "so and so suggested it in a office hour". Show us quotes from Linden Lab employees with location, date, and time. ________________________________ From: Melinda Green To: Cai Xiao(dynaturtle) Cc: sldev at lists.secondlife.com Sent: Tuesday, May 19, 2009 10:34:34 PM Subject: Re: [sldev] How to make speicific cyclinder Why do you want to do that when SL already supports cylinder primitives? I hope you do not want to implement individual polygons using sculpties. Proper polygon mesh primitives are definitely coming so it may be best to wait for that if you can. -Melinda Cai Xiao(dynaturtle) wrote: > Hello, guys! > I want to make cylinder whose bottom is arbitrary polygon using sculpt > texture. My idea is quite simple, just triangulate the cylinder in > order to get a triangles mesh. Then represent the mesh using sculpt > texture. But the result didn't meet my expect. I am not sure what is > wrong with it. Does anyone ever do relevant thing? And would you share > some experience with me? Thanks in advance! > > -- > Department of Spatial Information Science&Technology, > School of Earth&Space Science, Peking University > _______________________________________________ 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/20090519/bab401a4/attachment.htm From melinda at superliminal.com Wed May 20 00:03:44 2009 From: melinda at superliminal.com (Melinda Green) Date: Wed, 20 May 2009 00:03:44 -0700 Subject: [sldev] How to make speicific cyclinder In-Reply-To: References: <448f7bd20905191825t7a81ef3fudfcce67ad7c772fa@mail.gmail.com> <4A136C3A.3090802@superliminal.com> Message-ID: <4A13AB50.3050503@superliminal.com> Stickman wrote: >> Proper polygon mesh primitives are definitely coming so it may be best >> to wait for that if you can. >> > > I haven't heard ANYTHING about this, and I am very interested in it. > The few Jiras I've seen on the issue were so woefully lacking on > information that I feared to vote for them because there's no telling > what could get put in. I've been looking for time to build up a more > complete Jira on the issue of mesh primitives -- and riggable meshes. > > May I ask where you got this information, and if it's a source I can peruse? > > Thank you, > > Stickman > I know this because I was Coco Linden until recently, and the subject came up often in our discussions. Mesh support is certainly a very highly requested feature and I know that many Lindens want it as much as you do. I've done a fair bit of computational geometry and data visualization work in the past so I know exactly how you feel. Nobody that I know of is against the idea and as you can imagine, there has been some very early design and prototyping work done. I won't give names or details because I don't want to burden anyone in the lab, all of whom are working far too hard as it is. Just feel assured that this sort of thing is very important, and your requests and suggestions are definitely not being ignored. I don't know of any fundamental roadblocks. It just requires some due diligence and a Linden's concerted effort. There are simply only so many developers, designers, QA, etc. and issues of stability and usability must always take precedence over new features. I don't want to get anyone's hopes up but I do want you to take heart and to not try to torture the poor sculpties too far beyond their original intent. -Melinda From carlo at alinoe.com Wed May 20 03:59:55 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 20 May 2009 12:59:55 +0200 Subject: [sldev] Arbitrary mesh support In-Reply-To: <4A13AB50.3050503@superliminal.com> References: <448f7bd20905191825t7a81ef3fudfcce67ad7c772fa@mail.gmail.com> <4A136C3A.3090802@superliminal.com> <4A13AB50.3050503@superliminal.com> Message-ID: <20090520105955.GA12696@alinoe.com> On Wed, May 20, 2009 at 12:03:44AM -0700, Melinda Green wrote: > new features. I don't want to get anyone's hopes up but I do want you to > take heart and to not try to torture the poor sculpties too far beyond > their original intent. This seems to indicate that the new mesh support will be there within a year... If it takes longer I'll have to use sculptures in the meantime. -- Carlo Wood From secret.argent at gmail.com Wed May 20 05:54:06 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 20 May 2009 07:54:06 -0500 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <20090519112840.GA3561@alinoe.com> References: <20090518211130.04e51ce9.sldev@free.fr> <4A11BF17.8060002@lindenlab.com> <20090519112840.GA3561@alinoe.com> Message-ID: <38486DCB-CF4B-4F37-A32F-C9FE1A2B6B3A@gmail.com> On 2009-05-19, at 06:28, Carlo Wood wrote: > The problem of 'sensors' is that they do too many call backs to > (cpu intensive) LSL scripts. Namely, whenever the distance to > the sensor changes. Say what? Sensors don't do callbacks when the distance to the sensor changes. They do callbacks when the sense operation happens. If you have your sensor firing many times a second, that's laggy, yes, but that's a completely different issue. From soft at lindenlab.com Wed May 20 07:01:12 2009 From: soft at lindenlab.com (Soft) Date: Wed, 20 May 2009 09:01:12 -0500 Subject: [sldev] Open Source Meeting Thu 2pm 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 suzyq at pobox.com Wed May 20 07:49:48 2009 From: suzyq at pobox.com (Suzy Deffeyes) Date: Wed, 20 May 2009 09:49:48 -0500 Subject: [sldev] Understanding the viewer event queue code Message-ID: <2bd5b7f10905200749n73d3c689i7be70d9a566b637e@mail.gmail.com> I'm attempting to understand how the event queue in the viewer works, specifically, creating and registering new services. I'm thankful for the documentation in llhttpnode.h, but I'm still scratching my head a bit. In LLHTTPRegistrar::buildAllServices(), I see all the message/* type nodes getting registered, as well as the trusted-message one. I *thought* all one had to do to get something registered was to have something like this: LLHTTPRegistration gHTTPServiceAlphaBeta("/alpha/beta"); So I expected (hoped?) to see the services defined in llsdappservices.cpp in the call to buildAllServices....but i don't see them in the list being registered. Is there something else needed? Or some other mechanism being used? Are they added later? Also, is there a separate event queue opened with each child region that the viewer is connected to? Or is there only one with the region the agent is in? Thanks Suzy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090520/a4070296/attachment.htm From open at autistici.org Wed May 20 08:04:55 2009 From: open at autistici.org (Opensource Obscure) Date: Wed, 20 May 2009 15:04:55 +0000 Subject: [sldev] Crash stats from the past week In-Reply-To: <4A12DE30.4090603@lindenlab.com> References: <4A12DE30.4090603@lindenlab.com> Message-ID: On Tue, 19 May 2009 09:28:32 -0700, Rob Lanphier wrote: > Based on what I've seen from the crash reports, they still reduce down > to the following three bugs: > "http-texture branch viewer locks up and client must be killed, no crash > report is generated" > http://jira.secondlife.com/browse/VWR-13437 I'm definitively seeing this crash on Windows XP SP3, as I reported in a comment. I do not see that on Linux, on a comparable but different hardware configuration. I rarely have access to a Windows machine so my testing on this platform is limited, but I'd say Snowglobe crashes are currently too frequent on Windows to be acceptable; instead, on Linux Snowglobe is currently working quite well for me, apart some texture loading issues I'm still a bit confused about. oh - if you're on Friendfeed or plan to give it a try (it's basically a really smart social network), remember there is a Second Life group - I recently posted some information about Snowglobe, and a little conversation had place: http://friendfeed.com/secondlife/78c623d6/snowglobe-is-now-official-name-of-new-version ciao, opensource obscure -- http://twitter.com/oobscure From infinity at lindenlab.com Wed May 20 09:00:27 2009 From: infinity at lindenlab.com (Infinity Linden) Date: Wed, 20 May 2009 09:00:27 -0700 Subject: [sldev] Understanding the viewer event queue code In-Reply-To: <2bd5b7f10905200749n73d3c689i7be70d9a566b637e@mail.gmail.com> References: <2bd5b7f10905200749n73d3c689i7be70d9a566b637e@mail.gmail.com> Message-ID: <3a880e2c0905200900s69934f02h71309c752acc628a@mail.gmail.com> lemme dig through my notes and see if i have more / better documentation on using caps. yes. if the viewer is still as i remember it, we have an event queue for the region you're connected to and for each adjacent region for object updates from child cameras. (but... it's been close to a year since i touched the client code... though the llmessage code is shared between viewer and server.) On Wed, May 20, 2009 at 7:49 AM, Suzy Deffeyes wrote: > I'm attempting to understand how the event queue in the viewer works, > specifically, creating and registering new services. I'm thankful for the > documentation in llhttpnode.h, but I'm still scratching my head a bit. > > In LLHTTPRegistrar::buildAllServices(), I see all the message/* type nodes > getting registered, as well as the trusted-message one. I *thought* all one > had to do to get something registered was to have something like this: > > LLHTTPRegistration gHTTPServiceAlphaBeta("/alpha/beta"); > > So I expected (hoped?) to see the services defined in llsdappservices.cpp > in the call to buildAllServices....but i don't see them in the list being > registered. Is there something else needed? Or some other mechanism being > used? Are they added later? > > Also, is there a separate event queue opened with each child region that > the viewer is connected to? Or is there only one with the region the agent > is in? > Thanks > Suzy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090520/0e96dfc8/attachment.htm From lenglish5 at cox.net Wed May 20 10:33:00 2009 From: lenglish5 at cox.net (Lawson English) Date: Wed, 20 May 2009 10:33:00 -0700 Subject: [sldev] Understanding the viewer event queue code In-Reply-To: <3a880e2c0905200900s69934f02h71309c752acc628a@mail.gmail.com> References: <2bd5b7f10905200749n73d3c689i7be70d9a566b637e@mail.gmail.com> <3a880e2c0905200900s69934f02h71309c752acc628a@mail.gmail.com> Message-ID: <4A143ECC.6050607@cox.net> Infinity Linden wrote: > lemme dig through my notes and see if i have more / better > documentation on using caps. > > yes. if the viewer is still as i remember it, we have an event queue > for the region you're connected to and for each adjacent region for > object updates from child cameras. (but... it's been close to a year > since i touched the client code... though the llmessage code is shared > between viewer and server.) > > On Wed, May 20, 2009 at 7:49 AM, Suzy Deffeyes > wrote: > > I'm attempting to understand how the event queue in the viewer > works, specifically, creating and registering new services. I'm > thankful for the documentation in llhttpnode.h, but I'm still > scratching my head a bit. > > In LLHTTPRegistrar::buildAllServices(), I see all the message/* > type nodes getting registered, as well as the trusted-message > one. I *thought* all one had to do to get something registered > was to have something like this: > > LLHTTPRegistration gHTTPServiceAlphaBeta("/alpha/beta"); > > So I expected (hoped?) to see the services defined in > llsdappservices.cpp in the call to buildAllServices....but i don't > see them in the list being registered. Is there something else > needed? Or some other mechanism being used? Are they added later? > > Also, is there a separate event queue opened with each child > region that the viewer is connected to? Or is there only one with > the region the agent is in? > Thanks > Suzy > Enus has implemented rudimentary test code for child region events in pyogp. It MIGHT be useful to see how he does it since the pyogp code is so minimal compared to the GPL client. http://wiki.secondlife.com/wiki/Pyogp/Client_Lib http://wiki.secondlife.com/wiki/Pyogp/Client_Lib/The_Development_Sandbox Lawson From tess at lindenlab.com Wed May 20 12:24:03 2009 From: tess at lindenlab.com (Tess Chu) Date: Wed, 20 May 2009 12:24:03 -0700 Subject: [sldev] Understanding the viewer event queue code In-Reply-To: <3a880e2c0905200900s69934f02h71309c752acc628a@mail.gmail.com> References: <2bd5b7f10905200749n73d3c689i7be70d9a566b637e@mail.gmail.com> <3a880e2c0905200900s69934f02h71309c752acc628a@mail.gmail.com> Message-ID: <9A659491-3C84-4267-96CC-3A13B9A9CA0C@lindenlab.com> The viewer requests for capabilities via the seed capability. "EventQueueGet" is the capability for polling for events queues for the client from the region. The viewer then periodically invokes that capability essentially polling the server for messages. See llviewerregion.cpp, lleventpoll.cpp. There are then routing code that maps the events received to the registered http handlers that you see. - Tess Sent from my iPhone On May 20, 2009, at 9:00 AM, Infinity Linden wrote: > lemme dig through my notes and see if i have more / better > documentation on using caps. > > yes. if the viewer is still as i remember it, we have an event queue > for the region you're connected to and for each adjacent region for > object updates from child cameras. (but... it's been close to a year > since i touched the client code... though the llmessage code is > shared between viewer and server.) > > On Wed, May 20, 2009 at 7:49 AM, Suzy Deffeyes > wrote: > I'm attempting to understand how the event queue in the viewer > works, specifically, creating and registering new services. I'm > thankful for the documentation in llhttpnode.h, but I'm still > scratching my head a bit. > > In LLHTTPRegistrar::buildAllServices(), I see all the message/* type > nodes getting registered, as well as the trusted-message one. I > *thought* all one had to do to get something registered was to have > something like this: > > LLHTTPRegistration gHTTPServiceAlphaBeta("/alpha/beta"); > > So I expected (hoped?) to see the services defined in > llsdappservices.cpp in the call to buildAllServices....but i don't > see them in the list being registered. Is there something else > needed? Or some other mechanism being used? Are they added later? > > Also, is there a separate event queue opened with each child region > that the viewer is connected to? Or is there only one with the > region the agent is in? > Thanks > Suzy > > > _______________________________________________ > 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/20090520/896ad128/attachment.htm From philip at lindenlab.com Wed May 20 12:49:08 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Wed, 20 May 2009 12:49:08 -0700 Subject: [sldev] VWR-10311 : Lip Sync enabling patch In-Reply-To: <266514F2-81B7-4688-8B2D-3C4FA6FE088E@lindenlab.com> References: <266514F2-81B7-4688-8B2D-3C4FA6FE088E@lindenlab.com> Message-ID: <4A145EB4.50301@lindenlab.com> thx mike! We need a love machine for sldev. Philippe Bossut (Merov Linden) wrote: > Hi guys, > > I reviewed Mike's patches and tweaked a little: > - suppressed the Advanced menu item > - added French l10n > > I attached a new patch to VWR-10311 covering both VWR-10311 and > VWR-13260. > > Mike, review appreciated :) > > Cheers, > - Merov > _______________________________________________ > 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 suzyq at pobox.com Wed May 20 12:51:51 2009 From: suzyq at pobox.com (Suzy Deffeyes) Date: Wed, 20 May 2009 14:51:51 -0500 Subject: [sldev] Understanding the viewer event queue code In-Reply-To: <9A659491-3C84-4267-96CC-3A13B9A9CA0C@lindenlab.com> References: <2bd5b7f10905200749n73d3c689i7be70d9a566b637e@mail.gmail.com> <3a880e2c0905200900s69934f02h71309c752acc628a@mail.gmail.com> <9A659491-3C84-4267-96CC-3A13B9A9CA0C@lindenlab.com> Message-ID: <2bd5b7f10905201251l143620s90de474b84a4074e@mail.gmail.com> Thanks Tess, It's the registration part that I'm hung up on. I grok the cap and the polling part, but there are a bunch of LLHTTPRegistration entries for event types that aren't in the list processed by LLHTTPRegistrar::buildAllServices(), which confused me. I thought that anything with an entry similar to this: LLHTTPRegistration gHTTPServiceAlphaBeta("/alpha/beta"); would show up in the list sent in to buildAllServices(). It doesn't appear to work quite that way. SQ On Wed, May 20, 2009 at 2:24 PM, Tess Chu wrote: > The viewer requests for capabilities via the seed capability. > "EventQueueGet" is the capability for polling for events queues for the > client from the region. The viewer then periodically invokes that > capability essentially polling the server for messages. See > llviewerregion.cpp, lleventpoll.cpp. There are then routing code that maps > the events received to the registered http handlers that you see. > > - Tess > Sent from my iPhone > > On May 20, 2009, at 9:00 AM, Infinity Linden > wrote: > > lemme dig through my notes and see if i have more / better documentation on > using caps. > yes. if the viewer is still as i remember it, we have an event queue for > the region you're connected to and for each adjacent region for object > updates from child cameras. (but... it's been close to a year since i > touched the client code... though the llmessage code is shared between > viewer and server.) > > On Wed, May 20, 2009 at 7:49 AM, Suzy Deffeyes < > suzyq at pobox.com> wrote: > >> I'm attempting to understand how the event queue in the viewer works, >> specifically, creating and registering new services. I'm thankful for the >> documentation in llhttpnode.h, but I'm still scratching my head a bit. >> >> In LLHTTPRegistrar::buildAllServices(), I see all the message/* type nodes >> getting registered, as well as the trusted-message one. I *thought* all one >> had to do to get something registered was to have something like this: >> >> LLHTTPRegistration gHTTPServiceAlphaBeta("/alpha/beta"); >> >> So I expected (hoped?) to see the services defined in llsdappservices.cpp >> in the call to buildAllServices....but i don't see them in the list being >> registered. Is there something else needed? Or some other mechanism being >> used? Are they added later? >> >> Also, is there a separate event queue opened with each child region that >> the viewer is connected to? Or is there only one with the region the agent >> is in? >> Thanks >> Suzy >> >> > _______________________________________________ > 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/20090520/cd087f83/attachment.htm From robla at lindenlab.com Wed May 20 12:56:07 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 20 May 2009 12:56:07 -0700 Subject: [sldev] Give easybuild-2 a whirl Message-ID: <4A146057.5060507@lindenlab.com> Hi all, It looks like easybuild-2 is getting close to ready for primetime (at least to me) Build instructions are reasonably straightforward (at least on Ubuntu 8.10). You *should* be able to just do the following: 1. Check out the easybuild-2 branch: svn co https://svn.secondlife.com/svn/linden/projects/2009/easybuild-2 2. Grab the artwork and the libs and unpack them in the right place Now there's a split depending on whether or not you like GUIs GUI: 3. Run cmake-gui 4. Pick your source dir to be the indra directory of your source tree 5. Pick your binary dir to be some place where you don't mind having a gazillion .o files laying around 6. Click "Configure" 7. Review the defaults 8 . Click "Generate" 8. Now use your tool of choice to build from indra (or type "make") Command line 3. cd indra 4. cmake . (optionally put the -D option to specify your target binary directory....I'll let someone else here chime in with exact syntax) 5. make These instructions probably grossly oversimplify things. I wasn't installing on a clean machine, so there's probably all sorts of prep work I'm glossing over. If you're new to building the viewer, you'll probably want to consult the build instructions here: https://wiki.secondlife.com/wiki/Get_source_and_compile However, we'd appreciate it if the more adventurous among you would give this branch a shot. Thanks Rob From robla at lindenlab.com Wed May 20 13:10:39 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 20 May 2009 13:10:39 -0700 Subject: [sldev] Closing out the merge window Message-ID: <4A1463BF.2030802@lindenlab.com> Hi folks, We've got some rebranding stuff we still need to get done, but otherwise, let's close out the merge window for this release. How does 6pm PDT Friday sound? Here's the current queue: https://wiki.secondlife.com/wiki/Snowglobe_Current_Cycle ...and here's the dev process where "merge queue" is explained: https://wiki.secondlife.com/wiki/Snowglobe_Development_Process Rob From johnniecarling at gmail.com Wed May 20 15:18:18 2009 From: johnniecarling at gmail.com (Johnnie Carling) Date: Wed, 20 May 2009 18:18:18 -0400 Subject: [sldev] Give easybuild-2 a whirl In-Reply-To: <4A146057.5060507@lindenlab.com> References: <4A146057.5060507@lindenlab.com> Message-ID: <200905201818.19330.johnniecarling@gmail.com> > However, we'd appreciate it if the more adventurous among you would give > this branch a shot. /me whirls it using an updated this morning Debian Sid Built just fine using the command line In fact it was better than normal as I always have had to comment out the -Werror flag before. Johnnie Carling From jamey at beau.org Wed May 20 15:33:44 2009 From: jamey at beau.org (Jamey Fletcher) Date: Wed, 20 May 2009 17:33:44 -0500 Subject: [sldev] A thought on how to lower resources used by sensors In-Reply-To: <824c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com> References: <4A0F5CE5.2090307@gmail.com> <4A0FA697.2050706@gmail.com> <4A107003.1030808@boroon.dasgupta.ch> <824c8ab70905171916w3d60a28ck6b958ad60254940@mail.gmail.com> Message-ID: <4A148548.5020008@beau.org> Nexii Malthus wrote: > I think rather than keeping the problem on the LSL side, it would be > more suitable for being a viewer-side feature entirely that replaced the > necessity of such silly HUDs and Gadgets. Finally removing the source of > the problem alltogether, and virally so due to the big advantages of > being able to be tied into the user interface. I actually like having it going SIM side, exposed to LSL - different people want to crunch different things out of the data. Right now, the HUD I built gives me distance and relative direction, as well as all of the agent status flags, such as flying, typing, sitting, walking, etc... I rebuilt it out of a freebie one I found - and I then had it split the list of detected AVs into ones within chat range, and ones outside of chat range. The whole point being - I made it *MINE*, not a built-in part of the interface. That means it takes up the screen real estate I want - not the screen real estate of the mysti-tool, or the Friends window, or whatever you want to choose. Of course, should Linden Labs introduce avatar scanning into the UI, I will probably end up using it, just because it's there. But there's a fair chance I'll continue using mine, anyway. Because it does what *I* want it to do. From monkowsk at watson.ibm.com Wed May 20 15:50:36 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 20 May 2009 18:50:36 -0400 Subject: [sldev] Closing out the merge window In-Reply-To: <4A1463BF.2030802@lindenlab.com> References: <4A1463BF.2030802@lindenlab.com> Message-ID: <4A14893C.7030902@watson.ibm.com> I thought you still have crashing and freezing problems. Is it really ready to ship? Mike Rob Lanphier wrote: > Hi folks, > > We've got some rebranding stuff we still need to get done, but > otherwise, let's close out the merge window for this release. How does > 6pm PDT Friday sound? From malachi at tamzap.com Wed May 20 16:00:19 2009 From: malachi at tamzap.com (malachi at tamzap.com) Date: Wed, 20 May 2009 19:00:19 -0400 Subject: [sldev] help with build In-Reply-To: <4A14893C.7030902@watson.ibm.com> References: <4A1463BF.2030802@lindenlab.com> <4A14893C.7030902@watson.ibm.com> Message-ID: i finally sat down last night and started the new snowglobe build. and i found that there are hundreds of errors in my build. am i missing something that isnt used in the previous builds? any help is appreciated. cause im completely lost lol From aimee.trescothick at gmail.com Wed May 20 16:48:45 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Thu, 21 May 2009 00:48:45 +0100 Subject: [sldev] Closing out the merge window In-Reply-To: <4A14893C.7030902@watson.ibm.com> References: <4A1463BF.2030802@lindenlab.com> <4A14893C.7030902@watson.ibm.com> Message-ID: <8475573D-BB08-4B99-AC10-7D3D5E98F341@gmail.com> On 20 May 2009, at 23:50, Mike Monkowski wrote: > I thought you still have crashing and freezing problems. Is it really > ready to ship? Closing the merge window doesn't mean ready to ship, just no new features this cycle. Next follows the Stabilzation phase for bug fixing, at the end of which we have RC and finally Release, before starting all over again. https://wiki.secondlife.com/wiki/ SLDev_Viewer_Development_Process#Release_cycle Aimee. From robla at lindenlab.com Wed May 20 17:01:41 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 20 May 2009 17:01:41 -0700 Subject: [sldev] Code review: VWR-13615: Snowglobe build failure in llimageworker_test.cpp: 'transform' is not a member of 'std' Message-ID: <4A1499E5.5010705@lindenlab.com> Hi all, I'm hoping to slip a one-liner in...just need a code review: http://jira.secondlife.com/browse/VWR-13615 One liner fix for compiling on Ubuntu Intrepid. Index: tests/llimageworker_test.cpp =================================================================== --- tests/llimageworker_test.cpp (revision 2292) +++ tests/llimageworker_test.cpp (working copy) @@ -34,6 +34,7 @@ // Precompiled header: almost always required for newview cpp files #include #include +#include // Class to test #include "../llimageworker.h" // For timer class Anyone bothered by me checking this in? Rob From robla at lindenlab.com Wed May 20 17:06:32 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 20 May 2009 17:06:32 -0700 Subject: [sldev] Closing out the merge window In-Reply-To: <4A14893C.7030902@watson.ibm.com> References: <4A1463BF.2030802@lindenlab.com> <4A14893C.7030902@watson.ibm.com> Message-ID: <4A149B08.4010208@lindenlab.com> Hi Mike, Nope, it's not ready to ship. "Closing out the merge window" means "no new features, just bug fixes". See: https://wiki.secondlife.com/wiki/Snowglobe_Development_Process#Release_cycle The more features we add, the more risk we'll add new bugs. We want to stop adding stuff and stabilize it. Rob On 05/20/2009 03:50 PM, Mike Monkowski wrote: > I thought you still have crashing and freezing problems. Is it really > ready to ship? > > Mike > > > Rob Lanphier wrote: >> Hi folks, >> >> We've got some rebranding stuff we still need to get done, but >> otherwise, let's close out the merge window for this release. How does >> 6pm PDT Friday sound? From robla at lindenlab.com Wed May 20 17:56:33 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 20 May 2009 17:56:33 -0700 Subject: [sldev] s/Second Life/Snowglobe/g Message-ID: <4A14A6C1.7020705@lindenlab.com> Check out these messages notifications.xml: Viewer: notifications.xml:Cache will be cleared after you restart [SECOND_LIFE]. notifications.xml:Cache will be moved after you restart [SECOND_LIFE]. notifications.xml:Port settings take effect after you restart [SECOND_LIFE]. notifications.xml:The new skin will appear after you restart [SECOND_LIFE]. notifications.xml:[SECOND_LIFE] crashed while initializing graphics drivers. notifications.xml:You can still look at existing IM and chat by clicking 'View IM & Chat'. Otherwise, click 'Quit' to exit [SECOND_LIFE] immediately. notifications.xml:[SECOND_LIFE] installation is complete. notifications.xml:A new version of [SECOND_LIFE] is available. notifications.xml:An updated version of [SECOND_LIFE] is available. notifications.xml:A new version of [SECOND_LIFE] is available. Website: notifications.xml:You can propose to another Resident or dissolve an existing partnership through the [SECOND_LIFE] website. notifications.xml:Go to the [SECOND_LIFE] events web page? notifications.xml:Go to the [SECOND_LIFE] web page to see auction details or make a bid? notifications.xml:Visit the [SECOND_LIFE] Wiki and learn how to report bugs correctly. notifications.xml:Visit the [SECOND_LIFE] Wiki for details of how to report a security issue. notifications.xml:Visit the [SECOND_LIFE] QA Wiki. notifications.xml:Visit the [SECOND_LIFE] Public Issue Tracker, where you can report bugs and other issues. notifications.xml:Visit the [SECOND_LIFE] Wiki for info on how to use the Public Issue Tracker. The world: notifications.xml:You must agree to the Terms of Service to continue logging into [SECOND_LIFE]. notifications.xml:You need an account to enter [SECOND_LIFE]. Would you like to create one now? notifications.xml:You have been logged out of [SECOND_LIFE]: notifications.xml:You can build new objects in some areas of [SECOND_LIFE]. Ambiguous: notifications.xml:You can use [SECOND_LIFE] normally and other users will see you correctly. notifications.xml:If this is your first time using [SECOND_LIFE], you will need to create an account before you can log on. notifications.xml:Press the F1 key at any time for help or to learn more about [SECOND_LIFE]. notifications.xml:You must download this update to use [SECOND_LIFE]. Here's my thinking on how to tackle this. Let's do the least disruptive thing for now, which is to replace the instances of [SECOND_LIFE] in the "Viewer" category with [VIEWERNAME], and then make [VIEWERNAME]="Snowglobe" Since we're not likely to change the "Second Life" string for those in this release, we can leave the others "SECOND_LIFE" for now. There's a lot of bikeshed arguments about what to name the other categories, but it'll be more obvious not only what to name the new token but where it should be sourced from at the time that we're ready to change those to other values. Sound reasonable? Rob From dynaturtle.cai at gmail.com Wed May 20 18:19:48 2009 From: dynaturtle.cai at gmail.com (Cai Xiao(dynaturtle)) Date: Thu, 21 May 2009 09:19:48 +0800 Subject: [sldev] How to make speicific cyclinder In-Reply-To: <4A13AB50.3050503@superliminal.com> References: <448f7bd20905191825t7a81ef3fudfcce67ad7c772fa@mail.gmail.com> <4A136C3A.3090802@superliminal.com> <4A13AB50.3050503@superliminal.com> Message-ID: <448f7bd20905201819kf9b39e1v537b4a85552f5c1d@mail.gmail.com> Well, personally, I think it is a good news. I am looking forward for this new feature. On Wed, May 20, 2009 at 3:03 PM, Melinda Green wrote: > Stickman wrote: > >> Proper polygon mesh primitives are definitely coming so it may be best >>> to wait for that if you can. >>> >>> >> >> I haven't heard ANYTHING about this, and I am very interested in it. >> The few Jiras I've seen on the issue were so woefully lacking on >> information that I feared to vote for them because there's no telling >> what could get put in. I've been looking for time to build up a more >> complete Jira on the issue of mesh primitives -- and riggable meshes. >> >> May I ask where you got this information, and if it's a source I can >> peruse? >> >> Thank you, >> >> Stickman >> >> > > I know this because I was Coco Linden until recently, and the subject came > up often in our discussions. Mesh support is certainly a very highly > requested feature and I know that many Lindens want it as much as you do. > I've done a fair bit of computational geometry and data visualization work > in the past so I know exactly how you feel. Nobody that I know of is against > the idea and as you can imagine, there has been some very early design and > prototyping work done. I won't give names or details because I don't want to > burden anyone in the lab, all of whom are working far too hard as it is. > Just feel assured that this sort of thing is very important, and your > requests and suggestions are definitely not being ignored. I don't know of > any fundamental roadblocks. It just requires some due diligence and a > Linden's concerted effort. There are simply only so many developers, > designers, QA, etc. and issues of stability and usability must always take > precedence over new features. I don't want to get anyone's hopes up but I do > want you to take heart and to not try to torture the poor sculpties too far > beyond their original intent. > > -Melinda > -- Department of Spatial Information Science&Technology, School of Earth&Space Science, Peking University ADD: Room 3028, Building 46, Peking University, Beijing, P.R. China Zip Code: 100871 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090521/c9f70bb5/attachment.htm From dzonatas at gmail.com Wed May 20 18:41:25 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Wed, 20 May 2009 18:41:25 -0700 Subject: [sldev] s/Second Life/Snowglobe/g In-Reply-To: <4A14A6C1.7020705@lindenlab.com> References: <4A14A6C1.7020705@lindenlab.com> Message-ID: <4A14B145.9000802@gmail.com> Since you have already started to tackle the name change, I ask for a bit more thought on this path. SECOND_LIFE, and even the two letters LL, has been known and used for all things related to the viewer (UI), server, render engine, and network. That has worked in general so far. With a variable name like VIEWERNAME, however, it is explicit to the viewer and maybe with the render engine and network bundled together it implies those also. What happens when one separates the viewer (UI) from the render engine and network parts. What do we call the render engine and network? Or perhaps the render engine and network is best known as Snowglobe and viewer is a client of Snowglobe's render engine and network? I hope you see this issue I bring up here. Maybe the best way to think of it is in Debian terms. What if (in Debian world), the render engine and network code is distributed as libsnowglobe.so and the viewer (UI) that loads libsnowglobe is distributed as.... as what? Snowglobe also? If this is fine with everybody then ok! If you think it needs more thought than that, maybe there needs to be [RENDERNAME], [NETWORKNAME], [SERVERNAME], or something else that is not bundled into VIEWERNAME that would work when there is no UI code (i.e. just the shared library for a render engine and network code). Cache will be cleared after you restart Rosebud Rob Lanphier wrote: > ... > Here's my thinking on how to tackle this. Let's do the least disruptive > thing for now, which is to replace the instances of [SECOND_LIFE] in the > "Viewer" category with [VIEWERNAME], and then make > [VIEWERNAME]="Snowglobe" Since we're not likely to change the "Second > Life" string for those in this release, we can leave the others > "SECOND_LIFE" for now. There's a lot of bikeshed arguments about what > to name the other categories, but it'll be more obvious not only what to > name the new token but where it should be sourced from at the time that > we're ready to change those to other values. > > Sound reasonable? > > Rob > From tigrospottystripes at gmail.com Wed May 20 18:32:33 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 20 May 2009 22:32:33 -0300 Subject: [sldev] s/Second Life/Snowglobe/g In-Reply-To: <4A14B145.9000802@gmail.com> References: <4A14A6C1.7020705@lindenlab.com> <4A14B145.9000802@gmail.com> Message-ID: <4A14AF31.5040804@Gmail.com> isn't there some spots where the grid or other LL services are referred to as "Second Life"? Dzonatas Sol escreveu: > Since you have already started to tackle the name change, I ask for a > bit more thought on this path. SECOND_LIFE, and even the two letters LL, > has been known and used for all things related to the viewer (UI), > server, render engine, and network. That has worked in general so far. > With a variable name like VIEWERNAME, however, it is explicit to the > viewer and maybe with the render engine and network bundled together it > implies those also. What happens when one separates the viewer (UI) from > the render engine and network parts. What do we call the render engine > and network? Or perhaps the render engine and network is best known as > Snowglobe and viewer is a client of Snowglobe's render engine and > network? I hope you see this issue I bring up here. > > Maybe the best way to think of it is in Debian terms. What if (in Debian > world), the render engine and network code is distributed as > libsnowglobe.so and the viewer (UI) that loads libsnowglobe is > distributed as.... as what? Snowglobe also? If this is fine with > everybody then ok! > > If you think it needs more thought than that, maybe there needs to be > [RENDERNAME], [NETWORKNAME], [SERVERNAME], or something else that is not > bundled into VIEWERNAME that would work when there is no UI code (i.e. > just the shared library for a render engine and network code). > > Cache will be cleared after you restart Rosebud > > Rob Lanphier wrote: > >> ... >> Here's my thinking on how to tackle this. Let's do the least disruptive >> thing for now, which is to replace the instances of [SECOND_LIFE] in the >> "Viewer" category with [VIEWERNAME], and then make >> [VIEWERNAME]="Snowglobe" Since we're not likely to change the "Second >> Life" string for those in this release, we can leave the others >> "SECOND_LIFE" for now. There's a lot of bikeshed arguments about what >> to name the other categories, but it'll be more obvious not only what to >> name the new token but where it should be sourced from at the time that >> we're ready to change those to other values. >> >> Sound reasonable? >> >> 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 melinda at superliminal.com Wed May 20 18:42:00 2009 From: melinda at superliminal.com (Melinda Green) Date: Wed, 20 May 2009 18:42:00 -0700 Subject: [sldev] s/Second Life/Snowglobe/g In-Reply-To: <4A14A6C1.7020705@lindenlab.com> References: <4A14A6C1.7020705@lindenlab.com> Message-ID: <4A14B168.1000708@superliminal.com> Rob Lanphier wrote: > Check out these messages notifications.xml: > > Viewer: > notifications.xml:Cache will be cleared after you restart [SECOND_LIFE]. > notifications.xml:Cache will be moved after you restart [SECOND_LIFE]. > notifications.xml:Port settings take effect after you restart [SECOND_LIFE]. > notifications.xml:The new skin will appear after you restart [SECOND_LIFE]. > notifications.xml:[SECOND_LIFE] crashed while initializing graphics drivers. > notifications.xml:You can still look at existing IM and chat by clicking > 'View IM & Chat'. Otherwise, click 'Quit' to > exit [SECOND_LIFE] immediately. > notifications.xml:[SECOND_LIFE] installation is complete. > notifications.xml:A new version of [SECOND_LIFE] is available. > notifications.xml:An updated version of [SECOND_LIFE] is available. > notifications.xml:A new version of [SECOND_LIFE] is available. > > Website: > notifications.xml:You can propose to another Resident or dissolve an > existing partnership through the [SECOND_LIFE] website. > notifications.xml:Go to the [SECOND_LIFE] events web page? > notifications.xml:Go to the [SECOND_LIFE] web page to see auction > details or make a bid? > notifications.xml:Visit the [SECOND_LIFE] Wiki and learn how to report > bugs correctly. > notifications.xml:Visit the [SECOND_LIFE] Wiki for details of how to > report a security issue. > notifications.xml:Visit the [SECOND_LIFE] QA Wiki. > notifications.xml:Visit the [SECOND_LIFE] Public Issue Tracker, where > you can report bugs and other issues. > notifications.xml:Visit the [SECOND_LIFE] Wiki for info on how to use > the Public Issue Tracker. > > The world: > notifications.xml:You must agree to the Terms of Service to continue > logging into [SECOND_LIFE]. > notifications.xml:You need an account to enter [SECOND_LIFE]. Would you > like to create one now? > notifications.xml:You have been logged out of [SECOND_LIFE]: > notifications.xml:You can build new objects in some areas of [SECOND_LIFE]. > > Ambiguous: > notifications.xml:You can use [SECOND_LIFE] normally and other users > will see you correctly. > notifications.xml:If this is your first time using [SECOND_LIFE], you > will need to create an account before you can log on. > notifications.xml:Press the F1 key at any time for help or to learn more > about [SECOND_LIFE]. > notifications.xml:You must download this update to use [SECOND_LIFE]. > > Here's my thinking on how to tackle this. Let's do the least disruptive > thing for now, which is to replace the instances of [SECOND_LIFE] in the > "Viewer" category with [VIEWERNAME], and then make > [VIEWERNAME]="Snowglobe" Since we're not likely to change the "Second > Life" string for those in this release, we can leave the others > "SECOND_LIFE" for now. There's a lot of bikeshed arguments about what > to name the other categories, but it'll be more obvious not only what to > name the new token but where it should be sourced from at the time that > we're ready to change those to other values. > > Sound reasonable? It's trickier than that. For one thing, for this to do what you want, we need to distinguish between "Second Life" the place, and "Second Life" the viewer. For example, we don't want to say "You need an account to enter Snowglobe". Users will still be logging into Second Life, they'll just be using Snowglobe to do that. Some of these problems might be fixed by simply removing a few of the items from your list. The other thing I highly suggest is to try to stop using the term "viewer", or at least think of that term as part of the name of the other one. In this case that means using the tag CLIENT_NAME instead of VIEWER_NAME. This way the new *client* name is "Snowglobe" while the old client has the awful name "The Second Life Viewer". Putting it all together and creating a worst case example, imagine a message that contains both the client and world concepts. Imagine that you want the English version to say "Snowglobe has lost contact with Second Life. Please check your Internet connection." We'd then need an entry in notifications.txt that reads "[CLIENT_NAME] has lost contact with [SECOND_LIFE]. Please check your Internet connection." It may be a straight forward task but it's not trivial. We can quibble over the client verses viewer thing but I think that all of the above needs to happen. The only question is whether you've missed the merge window in which to do it. ;-) -Melinda From sheet.spotter at gmail.com Wed May 20 19:35:16 2009 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Wed, 20 May 2009 21:35:16 -0500 Subject: [sldev] HTTP-texture documentation In-Reply-To: References: <008DCEB4990C48B3B0EB301124E1C88D@kenb> Message-ID: <07794218F7DF42229282B4B6189A13D0@kenb> There were no objections, so two simplified class diagrams have been added to the Threads section of the HTTP Texture wiki page. https://wiki.secondlife.com/wiki/HTTP_Texture The original explanation of the threads and workers remains unchanged; only a brief reference to the two diagrams was added at the start of the Threads section. The simplified class diagrams were created in Visual Studio 2005 by manually creating empty C# classes with the same names as the original source code, and using the "Export Diagram as Image." feature from the C# Class Diagram. I would love to know if there is an easier (and free) way of creating simplified class diagrams, or if there is a format that LL would prefer. Sheet Spotter _____ From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Moriz Gupte Sent: May 19, 2009 11:38 PM To: Second Life Developer Mailing List Subject: Re: [sldev] HTTP-texture documentation Hey sheet, I find this approach of presenting the architecture helpful (but this is personal of course). My vote is yes. R On Tue, May 19, 2009 at 10:33 PM, Sheet Spotter wrote: Would the attached class diagram be a welcome addition to the description of threads on the HTTP Texture wiki page? http://wiki.secondlife.com/wiki/HTTP_Texture -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090520/cd9caf6f/attachment.htm From robin.cornelius at gmail.com Thu May 21 04:58:36 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 21 May 2009 12:58:36 +0100 Subject: [sldev] help with build In-Reply-To: References: <4A1463BF.2030802@lindenlab.com> <4A14893C.7030902@watson.ibm.com> Message-ID: On Thu, May 21, 2009 at 12:00 AM, wrote: > i finally sat down last night and started the new snowglobe build. and i > found that there are hundreds of errors in my build. am i missing something > that isnt used in the previous builds? any help is appreciated. cause im > completely lost lol Sounds like something fundamental is missing. Can you at least explain what stages you have followed and where it has gone wrong, and grab the build log. The most interesting errors will be the very first ones, everything else is just a cascading failure from the early ones. With out at least that its very difficult for anyone to provide any help Robin From q at lindenlab.com Thu May 21 06:01:43 2009 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Thu, 21 May 2009 09:01:43 -0400 Subject: [sldev] s/Second Life/Snowglobe/g In-Reply-To: <4A14B145.9000802@gmail.com> References: <4A14A6C1.7020705@lindenlab.com> <4A14B145.9000802@gmail.com> Message-ID: That's exactly the point of Rob's proposal. The viewer is unambiguous and not particularly controversial. The rest of it is open to delightful amounts of bikeshedding. His proposal is to fix the viewer only for this round, and have the rest of the discussion later. Q On May 20, 2009, at 9:41 PM, Dzonatas Sol wrote: > Since you have already started to tackle the name change, I ask for a > bit more thought on this path. SECOND_LIFE, and even the two letters > LL, > has been known and used for all things related to the viewer (UI), > server, render engine, and network. That has worked in general so far. > With a variable name like VIEWERNAME, however, it is explicit to the > viewer and maybe with the render engine and network bundled together > it > implies those also. What happens when one separates the viewer (UI) > from > the render engine and network parts. What do we call the render engine > and network? Or perhaps the render engine and network is best known as > Snowglobe and viewer is a client of Snowglobe's render engine and > network? I hope you see this issue I bring up here. > > Maybe the best way to think of it is in Debian terms. What if (in > Debian > world), the render engine and network code is distributed as > libsnowglobe.so and the viewer (UI) that loads libsnowglobe is > distributed as.... as what? Snowglobe also? If this is fine with > everybody then ok! > > If you think it needs more thought than that, maybe there needs to be > [RENDERNAME], [NETWORKNAME], [SERVERNAME], or something else that is > not > bundled into VIEWERNAME that would work when there is no UI code (i.e. > just the shared library for a render engine and network code). > > Cache will be cleared after you restart Rosebud > > Rob Lanphier wrote: >> ... >> Here's my thinking on how to tackle this. Let's do the least >> disruptive >> thing for now, which is to replace the instances of [SECOND_LIFE] >> in the >> "Viewer" category with [VIEWERNAME], and then make >> [VIEWERNAME]="Snowglobe" Since we're not likely to change the >> "Second >> Life" string for those in this release, we can leave the others >> "SECOND_LIFE" for now. There's a lot of bikeshed arguments about >> what >> to name the other categories, but it'll be more obvious not only >> what to >> name the new token but where it should be sourced from at the time >> that >> we're ready to change those to other values. >> >> Sound reasonable? >> >> 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 q at lindenlab.com Thu May 21 06:17:34 2009 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Thu, 21 May 2009 09:17:34 -0400 Subject: [sldev] s/Second Life/Snowglobe/g In-Reply-To: References: <4A14A6C1.7020705@lindenlab.com> <4A14B145.9000802@gmail.com> Message-ID: Wow, speaking of ambiguity -- what I *meant* -- and where the confusion may be coming from -- is that those messages that clearly refer to the viewer should be fixed now, and the messages that refer to other parts of the system should be debated and resolved later. On May 21, 2009, at 9:01 AM, Kent Quirk (Q Linden) wrote: > That's exactly the point of Rob's proposal. The viewer is unambiguous > and not particularly controversial. > > The rest of it is open to delightful amounts of bikeshedding. His > proposal is to fix the viewer only for this round, and have the rest > of the discussion later. > > Q > > On May 20, 2009, at 9:41 PM, Dzonatas Sol wrote: > >> Since you have already started to tackle the name change, I ask for a >> bit more thought on this path. SECOND_LIFE, and even the two letters >> LL, >> has been known and used for all things related to the viewer (UI), >> server, render engine, and network. That has worked in general so >> far. >> With a variable name like VIEWERNAME, however, it is explicit to the >> viewer and maybe with the render engine and network bundled together >> it >> implies those also. What happens when one separates the viewer (UI) >> from >> the render engine and network parts. What do we call the render >> engine >> and network? Or perhaps the render engine and network is best known >> as >> Snowglobe and viewer is a client of Snowglobe's render engine and >> network? I hope you see this issue I bring up here. >> >> Maybe the best way to think of it is in Debian terms. What if (in >> Debian >> world), the render engine and network code is distributed as >> libsnowglobe.so and the viewer (UI) that loads libsnowglobe is >> distributed as.... as what? Snowglobe also? If this is fine with >> everybody then ok! >> >> If you think it needs more thought than that, maybe there needs to be >> [RENDERNAME], [NETWORKNAME], [SERVERNAME], or something else that is >> not >> bundled into VIEWERNAME that would work when there is no UI code >> (i.e. >> just the shared library for a render engine and network code). >> >> Cache will be cleared after you restart Rosebud >> >> Rob Lanphier wrote: >>> ... >>> Here's my thinking on how to tackle this. Let's do the least >>> disruptive >>> thing for now, which is to replace the instances of [SECOND_LIFE] >>> in the >>> "Viewer" category with [VIEWERNAME], and then make >>> [VIEWERNAME]="Snowglobe" Since we're not likely to change the >>> "Second >>> Life" string for those in this release, we can leave the others >>> "SECOND_LIFE" for now. There's a lot of bikeshed arguments about >>> what >>> to name the other categories, but it'll be more obvious not only >>> what to >>> name the new token but where it should be sourced from at the time >>> that >>> we're ready to change those to other values. >>> >>> Sound reasonable? >>> >>> 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 carlo at alinoe.com Thu May 21 07:35:50 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 21 May 2009 16:35:50 +0200 Subject: [sldev] Code review: VWR-13615: Snowglobe build failure in llimageworker_test.cpp: 'transform' is not a member of 'std' In-Reply-To: <4A1499E5.5010705@lindenlab.com> References: <4A1499E5.5010705@lindenlab.com> Message-ID: <20090521143550.GA24348@alinoe.com> On Wed, May 20, 2009 at 05:01:41PM -0700, Rob Lanphier wrote: > Anyone bothered by me checking this in? It's perfect. -- Carlo Wood From carlo at alinoe.com Thu May 21 07:42:55 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 21 May 2009 16:42:55 +0200 Subject: [sldev] s/Second Life/Snowglobe/g In-Reply-To: <4A14A6C1.7020705@lindenlab.com> References: <4A14A6C1.7020705@lindenlab.com> Message-ID: <20090521144255.GB24348@alinoe.com> On Wed, May 20, 2009 at 05:56:33PM -0700, Rob Lanphier wrote: > Here's my thinking on how to tackle this. Let's do the least disruptive > thing for now, which is to replace the instances of [SECOND_LIFE] in the > "Viewer" category with [VIEWERNAME], and then make > [VIEWERNAME]="Snowglobe" Since we're not likely to change the "Second > Life" string for those in this release, we can leave the others > "SECOND_LIFE" for now. [...] > Sound reasonable? Also perfect. *CW approved Stamp* -- Carlo Wood From dzonatas at gmail.com Thu May 21 08:53:05 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 21 May 2009 08:53:05 -0700 Subject: [sldev] s/Second Life/Snowglobe/g In-Reply-To: References: <4A14A6C1.7020705@lindenlab.com> <4A14B145.9000802@gmail.com> Message-ID: <4A1578E1.9050809@gmail.com> I don't think there is confusion about that point. That path is obvious enough. For those of us that need some way to refer to LL code in difference to their/our own code being bundled together, we also don't want to cause disruption where we now refer to Snowglobe (i.e. libsnowglobe.so) without the default viewer. The cache is not part of the UI. You can't click on a cached asset. My Blizzard viewer may implement a LUA script, for example, that implements a click on its own UI. It has its own unique skin all written in LUA. However, it may have to handle a message like, "The new skin will appear after you restart [VIEWERNAME]." Ok, so I change [VIEWERNAME]="Blizzard" instead of Snowglobe. Now it has to handle the message, "A new version of [VIEWERNAME] is available." Now, that's not quite true since users of Blizzard won't need to download the full Snowglobe software, as they just need libsnowglobe.so. This is an example of where I ask for a bit more thought. Another example, "Cache will be cleared after you restart [VIEWERNAME]." If libsnowglobe.so exists then the Blizzard viewer can automate that step and unload and reload libsnowglobe.so. Of course one can hack all instances of [VIEWERNAME] to fit a new UI, but what if the message comes from the Second Life grid? How is the Blizzard viewer to know if [VIEWERNAME] should be replaced with Snowglobe or with Blizzard? Just thinking outside of the official box. Kent Quirk (Q Linden) wrote: > Wow, speaking of ambiguity -- what I *meant* -- and where the > confusion may be coming from -- is that those messages that clearly > refer to the viewer should be fixed now, and the messages that refer > to other parts of the system should be debated and resolved later. > > On May 21, 2009, at 9:01 AM, Kent Quirk (Q Linden) wrote: > >> That's exactly the point of Rob's proposal. The viewer is unambiguous >> and not particularly controversial. >> >> The rest of it is open to delightful amounts of bikeshedding. His >> proposal is to fix the viewer only for this round, and have the rest >> of the discussion later. >> >> Q >> >> On May 20, 2009, at 9:41 PM, Dzonatas Sol wrote: >> >>> Since you have already started to tackle the name change, I ask for a >>> bit more thought on this path. SECOND_LIFE, and even the two letters >>> LL, >>> has been known and used for all things related to the viewer (UI), >>> server, render engine, and network. That has worked in general so far. >>> With a variable name like VIEWERNAME, however, it is explicit to the >>> viewer and maybe with the render engine and network bundled together >>> it >>> implies those also. What happens when one separates the viewer (UI) >>> from >>> the render engine and network parts. What do we call the render engine >>> and network? Or perhaps the render engine and network is best known as >>> Snowglobe and viewer is a client of Snowglobe's render engine and >>> network? I hope you see this issue I bring up here. >>> >>> Maybe the best way to think of it is in Debian terms. What if (in >>> Debian >>> world), the render engine and network code is distributed as >>> libsnowglobe.so and the viewer (UI) that loads libsnowglobe is >>> distributed as.... as what? Snowglobe also? If this is fine with >>> everybody then ok! >>> >>> If you think it needs more thought than that, maybe there needs to be >>> [RENDERNAME], [NETWORKNAME], [SERVERNAME], or something else that is >>> not >>> bundled into VIEWERNAME that would work when there is no UI code (i.e. >>> just the shared library for a render engine and network code). >>> >>> Cache will be cleared after you restart Rosebud >>> >>> Rob Lanphier wrote: >>>> ... >>>> Here's my thinking on how to tackle this. Let's do the least >>>> disruptive >>>> thing for now, which is to replace the instances of [SECOND_LIFE] >>>> in the >>>> "Viewer" category with [VIEWERNAME], and then make >>>> [VIEWERNAME]="Snowglobe" Since we're not likely to change the >>>> "Second >>>> Life" string for those in this release, we can leave the others >>>> "SECOND_LIFE" for now. There's a lot of bikeshed arguments about >>>> what >>>> to name the other categories, but it'll be more obvious not only >>>> what to >>>> name the new token but where it should be sourced from at the time >>>> that >>>> we're ready to change those to other values. >>>> >>>> Sound reasonable? >>>> >>>> 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 sllists at boroon.dasgupta.ch Thu May 21 08:40:05 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 21 May 2009 17:40:05 +0200 Subject: [sldev] s/Second Life/Snowglobe/g In-Reply-To: <4A14B145.9000802@gmail.com> References: <4A14A6C1.7020705@lindenlab.com> <4A14B145.9000802@gmail.com> Message-ID: <4A1575D5.5050902@boroon.dasgupta.ch> [Again from my list address ... sorry Dzonatas for the duplicate] My two Linden cents to the bike shed inline ... Dzonatas Sol schrieb: > [...]With a variable name like VIEWERNAME, however, it is explicit to the > viewer and maybe with the render engine and network bundled together it > implies those also. What happens when one separates the viewer (UI) from > the render engine and network parts. What do we call the render engine > and network? Or perhaps the render engine and network is best known as > Snowglobe and viewer is a client of Snowglobe's render engine and > network? I hope you see this issue I bring up here. > I see the issue, but I don't think it has to concern us just now: While a separation of render engine, network parts and the rest of the client (the UI) is something we should aim for, it won't happen soon enough to not give us the time to think about the naming scheme for these components then. Already introducing the name tags for that scenario might not be worth it, because * the clientvi might be separated into different components than we'd think today. * if there are several nametags that evaluate to the same value until such a separation, some of the tags will have been used wrongly once we're ready to introduce new names for the single components, so we would have to look at those strings again anyway before changing the tags' value. * While after a clean separation, some components might deserve own names, some of these names might never or very seldom be shown to the end user. (Ask some not-so-technical firefox users if they know what 'Gecko' or 'XULRunner' are ...) > Maybe the best way to think of it is in Debian terms. What if (in Debian > world), the render engine and network code is distributed as > libsnowglobe.so and the viewer (UI) that loads libsnowglobe is > distributed as.... as what? Snowglobe also? If this is fine with > everybody then ok! > I think the name of the current render engine is "Windlight", so if it is still the 'same' once it's been separated out, that'd probably be the name for the component, too. But as long as Snowglobe is delivered as a monolithic product, we won't have to care. > If you think it needs more thought than that, maybe there needs to be > [RENDERNAME], [NETWORKNAME], [SERVERNAME], or something else that is not > bundled into VIEWERNAME that would work when there is no UI code (i.e. > just the shared library for a render engine and network code). > The separation of which there should be taken care of soon in respect to naming is the one on the server side (Agent Domain and Region Domain), because that's something that's already being worked on. Though, as this shouldn't have much impact on the client side strings, we should be able to move on independently of that development. > Cache will be cleared after you restart Rosebud > :-) Will you be able to restart Rosebud without also restarting Snowglobe? > Rob Lanphier wrote: > >> ... >> Here's my thinking on how to tackle this. Let's do the least disruptive >> thing for now, which is to replace the instances of [SECOND_LIFE] in the >> "Viewer" category with [VIEWERNAME], and then make >> [VIEWERNAME]="Snowglobe" Since we're not likely to change the "Second >> Life" string for those in this release, we can leave the others >> "SECOND_LIFE" for now. There's a lot of bikeshed arguments about what >> to name the other categories, but it'll be more obvious not only what to >> name the new token but where it should be sourced from at the time that >> we're ready to change those to other values. >> >> Sound reasonable? >> >> Rob Sounds reasonable to me. cheers Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090521/b69ea56e/attachment.htm From monkowsk at watson.ibm.com Thu May 21 08:52:04 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu, 21 May 2009 11:52:04 -0400 Subject: [sldev] Closing out the merge window In-Reply-To: <8475573D-BB08-4B99-AC10-7D3D5E98F341@gmail.com> References: <4A1463BF.2030802@lindenlab.com> <4A14893C.7030902@watson.ibm.com> <8475573D-BB08-4B99-AC10-7D3D5E98F341@gmail.com> Message-ID: <4A1578A4.8080307@watson.ibm.com> What's the point of RC and Release? Isn't every incarnation of Snowglobe going to be equivalent to a First Look stable build? I don't remember First Look going through a RC then Release series? The changes will go through the RC and Release series if they get cherry picked for the standard viewer. If you go with another RC series, then you'll have people running Snowglobe out of SVN builds, RC builds, and Release builds. You don't have a very big audience as it is. Fragmenting it won't help. Everyone will be aware that Snowglobe is an Alpha release. Snowglobe needs more than just minor bug fixes. See my comment at https://jira.secondlife.com/browse/VWR-13437 I think http://wiki.secondlife.com/wiki/Snowglobe_Current_Cycle needs a link to a JIRA query that will generate a list of open issues. I don't know how to make such a query, though. Mike Aimee Trescothick wrote: > On 20 May 2009, at 23:50, Mike Monkowski wrote: > >> I thought you still have crashing and freezing problems. Is it really >> ready to ship? > > > Closing the merge window doesn't mean ready to ship, just no new > features this cycle. Next follows the Stabilzation phase for bug > fixing, at the end of which we have RC and finally Release, before > starting all over again. > > https://wiki.secondlife.com/wiki/ > SLDev_Viewer_Development_Process#Release_cycle > > Aimee. > From dzonatas at gmail.com Thu May 21 09:42:42 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 21 May 2009 09:42:42 -0700 Subject: [sldev] s/Second Life/Snowglobe/g In-Reply-To: <4A1575D5.5050902@boroon.dasgupta.ch> References: <4A14A6C1.7020705@lindenlab.com> <4A14B145.9000802@gmail.com> <4A1575D5.5050902@boroon.dasgupta.ch> Message-ID: <4A158482.8060908@gmail.com> Boroondas Gupte wrote: > My two Linden cents to the bike shed inline ... I beg to differ about the bikeshed assumption here. > I see the issue, but I don't think it has to concern us just now: > While a separation of render engine, network parts and the rest of the > client (the UI) is something we should aim for, it won't happen soon > enough to not give us the time to think about the naming scheme for > these components then. Already introducing the name tags for that > scenario might not be worth it, because... Because... it has already happened: http://mono.dzonux.net/file/MonoVida-20090521.png Notice the communication window is completely detached from where it normally would, normally assumed, to be? It's not in "the box". From melinda at superliminal.com Thu May 21 10:38:06 2009 From: melinda at superliminal.com (Melinda Green) Date: Thu, 21 May 2009 10:38:06 -0700 Subject: [sldev] Closing out the merge window In-Reply-To: <4A1578A4.8080307@watson.ibm.com> References: <4A1463BF.2030802@lindenlab.com> <4A14893C.7030902@watson.ibm.com> <8475573D-BB08-4B99-AC10-7D3D5E98F341@gmail.com> <4A1578A4.8080307@watson.ibm.com> Message-ID: <4A15917E.9030103@superliminal.com> That's a great question. Even though in theory this could be a continuous release process, there are some practical reasons to do it in cycles. The main reason is that during the normal phase where features are added and changed, we will naturally introduce bugs that tend to accumulate over time. The stabilization phases bring the bug levels down to acceptable levels. If it ever turned out code quality stayed high enough throughout development then you could make a great case for skipping this bit of protocol but I doubt that will ever happen and I think that's OK. Another good reason for having release cycles is so that other parties can plan around them. One such party is LL who will want to cherry-pick from highly stable versions in order to inherit the fewest bugs in the process. Another party is the casual user who will only be willing to upgrade occasionally and will want to know which versions to grab. Yet another party is you! :-) Your private branch or copy that you work in will drift from the main Snowglobe branch and if your do a substantial (i.e. destabilizing) amount of work, you will want to merge approved changes back to Snowglobe when it is in a most stable phase so that the problems you introduce are most easily fixed. Even if you only intend to make small, infrequent changes, you will want to do that work when Snowglobe is most stable. I don't think that having a release cycle fragments a product. It simply regularizes the natural ebb and flow of quality and lets people plan around it. It's fine if we decide that Snowglobe's quality does not need to be as high as the main LL viewer (at the points where *its* quality is highest in its cycle). We just need to decide what our quality standard should be and then adjust the length of our stabilization phases in order to hit that target. -Melinda Mike Monkowski wrote: > What's the point of RC and Release? Isn't every incarnation of > Snowglobe going to be equivalent to a First Look stable build? I don't > remember First Look going through a RC then Release series? > > The changes will go through the RC and Release series if they get cherry > picked for the standard viewer. > > If you go with another RC series, then you'll have people running > Snowglobe out of SVN builds, RC builds, and Release builds. You don't > have a very big audience as it is. Fragmenting it won't help. Everyone > will be aware that Snowglobe is an Alpha release. > > Snowglobe needs more than just minor bug fixes. See my comment at > https://jira.secondlife.com/browse/VWR-13437 > > I think http://wiki.secondlife.com/wiki/Snowglobe_Current_Cycle needs a > link to a JIRA query that will generate a list of open issues. I > don't know how to make such a query, though. > > Mike > > Aimee Trescothick wrote: > >> On 20 May 2009, at 23:50, Mike Monkowski wrote: >> >> >>> I thought you still have crashing and freezing problems. Is it really >>> ready to ship? >>> >> Closing the merge window doesn't mean ready to ship, just no new >> features this cycle. Next follows the Stabilzation phase for bug >> fixing, at the end of which we have RC and finally Release, before >> starting all over again. >> >> https://wiki.secondlife.com/wiki/ >> SLDev_Viewer_Development_Process#Release_cycle >> >> Aimee. >> >> > > _______________________________________________ > 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 sllists at boroon.dasgupta.ch Thu May 21 10:59:12 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 21 May 2009 19:59:12 +0200 Subject: [sldev] Closing out the merge window In-Reply-To: <4A1578A4.8080307@watson.ibm.com> References: <4A1463BF.2030802@lindenlab.com> <4A14893C.7030902@watson.ibm.com> <8475573D-BB08-4B99-AC10-7D3D5E98F341@gmail.com> <4A1578A4.8080307@watson.ibm.com> Message-ID: <4A159670.2010900@boroon.dasgupta.ch> Mike Monkowski schrieb: > I think http://wiki.secondlife.com/wiki/Snowglobe_Current_Cycle needs a > link to a JIRA query that will generate a list of open issues. I > don't know how to make such a query, though. How about http://jira.secondlife.com/secure/IssueNavigator.jspa?type=1&version=10435&status=1&status=3&status=4 ? If that query's OK, I'll add it to the wiki article. cheers Boroondas From monkowsk at watson.ibm.com Thu May 21 11:11:30 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu, 21 May 2009 14:11:30 -0400 Subject: [sldev] Closing out the merge window In-Reply-To: <4A15917E.9030103@superliminal.com> References: <4A1463BF.2030802@lindenlab.com> <4A14893C.7030902@watson.ibm.com> <8475573D-BB08-4B99-AC10-7D3D5E98F341@gmail.com> <4A1578A4.8080307@watson.ibm.com> <4A15917E.9030103@superliminal.com> Message-ID: <4A159952.5000609@watson.ibm.com> Melinda Green wrote: > That's a great question. Even though in theory this could be a > continuous release process, there are some practical reasons to do it in > cycles. The main reason is that during the normal phase where features > are added and changed, we will naturally introduce bugs that tend to > accumulate over time. The stabilization phases bring the bug levels down > to acceptable levels. If it ever turned out code quality stayed high > enough throughout development then you could make a great case for > skipping this bit of protocol but I doubt that will ever happen and I > think that's OK. You're working from a paradigm different from any that I have known. To say, "that during the normal phase where features are added and changed, we will naturally introduce bugs that tend to accumulate over time" is astounding to me. Who lets bugs accumulate over time? If you assume that you're going to start with dirty code and hope to clean it up when you get a chance, you're kidding yourself. You should start with clean, well reviewed code and expect bugs caused by interactions to be fixed over time. If you tolerate junk, you'll get junk. > Another good reason for having release cycles is so that other parties > can plan around them. One such party is LL who will want to cherry-pick > from highly stable versions in order to inherit the fewest bugs in the > process. Another party is the casual user who will only be willing to > upgrade occasionally and will want to know which versions to grab. Yet > another party is you! :-) Your private branch or copy that you work in > will drift from the main Snowglobe branch and if your do a substantial > (i.e. destabilizing) amount of work, you will want to merge approved > changes back to Snowglobe when it is in a most stable phase so that the > problems you introduce are most easily fixed. Even if you only intend to > make small, infrequent changes, you will want to do that work when > Snowglobe is most stable. Snowglobe is alpha code. It's not a competitor to the production viewer. Each new feature will stabilize over time, but there's no need to stabilize the entire set of features, because the entire set will never be merged at once into the production viewer. You're not pulling files from Snowglobe, you're just pulling the changesets. If you want stablity, you work with the production viewer source, not Snowglobe. Any way you do it, you'll have to eventually merge back into code that's constantly changing. If Snowglobe is ever stable, it means people no longer are contributing. > I don't think that having a release cycle fragments a product. It simply > regularizes the natural ebb and flow of quality and lets people plan > around it. It's fine if we decide that Snowglobe's quality does not need > to be as high as the main LL viewer (at the points where *its* quality > is highest in its cycle). We just need to decide what our quality > standard should be and then adjust the length of our stabilization > phases in order to hit that target. I meant that it fragmented the audience of alpha testers. If you accept an ebb and flow of quality, be prepared for more ebb than flow. The standard should be "clean in," because the alternative is "garbage in; garbage out." Mike From monkowsk at watson.ibm.com Thu May 21 11:16:17 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu, 21 May 2009 14:16:17 -0400 Subject: [sldev] Closing out the merge window In-Reply-To: <4A159670.2010900@boroon.dasgupta.ch> References: <4A1463BF.2030802@lindenlab.com> <4A14893C.7030902@watson.ibm.com> <8475573D-BB08-4B99-AC10-7D3D5E98F341@gmail.com> <4A1578A4.8080307@watson.ibm.com> <4A159670.2010900@boroon.dasgupta.ch> Message-ID: <4A159A71.5060905@watson.ibm.com> I don't think so. Nothing shows up, and it should have caught VWR-13437. Mike Boroondas Gupte wrote: > Mike Monkowski schrieb: > >>I think http://wiki.secondlife.com/wiki/Snowglobe_Current_Cycle needs a >> link to a JIRA query that will generate a list of open issues. I >>don't know how to make such a query, though. > > How about > http://jira.secondlife.com/secure/IssueNavigator.jspa?type=1&version=10435&status=1&status=3&status=4 > ? If that query's OK, I'll add it to the wiki article. > > cheers > Boroondas > From robla at lindenlab.com Thu May 21 12:12:24 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 21 May 2009 12:12:24 -0700 Subject: [sldev] Crash stats from the past week Message-ID: <4A15A798.6020203@lindenlab.com> A little more info from the past week: 2009-05-21: Second Life OSS 1.23.2.2283: 1 crashes from 1 agents Second Life OSS 1.23.2.2259: 1 crashes from 1 agents 2009-05-20: Second Life OSS 1.23.2.2291: 4 crashes from 1 agents Second Life OSS 1.23.2.2283: 10 crashes from 6 agents 2009-05-19: Second Life OSS 1.23.2.2283: 6 crashes from 4 agents 2009-05-18: Second Life OSS 1.23.2.2283: 25 crashes from 6 agents, 27.15 hours, 73 sessions, 22 agents Second Life OSS 1.23.2.2259: 1 crashes from 1 agents, 0.67 hours, 2 sessions, 1 agents Second Life OSS 1.23.2.120248: 0 crashes from 0 agents, 0.45 hours, 3 sessions, 1 agents Second Life OSS 1.23.0.2244: 0 crashes from 0 agents, 1.03 hours, 1 sessions, 1 agents 2009-05-17: Second Life OSS 1.23.2.2283: 2 crashes from 1 agents, 0.12 hours, 4 sessions, 1 agents Second Life OSS 1.23.2.2259: 0 crashes from 0 agents, 16.62 hours, 16 sessions, 7 agents Second Life OSS 1.23.0.2244: 0 crashes from 0 agents, 0.00 hours, 2 sessions, 1 agents 2009-05-16: Second Life OSS 1.23.2.2259: 3 crashes from 3 agents, 29.12 hours, 22 sessions, 6 agents Second Life OSS 1.23.0.2244: 0 crashes from 0 agents, 1.83 hours, 4 sessions, 4 agents Second Life OSS 1.23.0.2235: 0 crashes from 0 agents, 0.12 hours, 1 sessions, 1 agents 2009-05-15: Second Life OSS 1.23.2.2259: 2 crashes from 2 agents, 19.98 hours, 35 sessions, 13 agents Second Life OSS 1.23.0.2244: 1 crashes from 1 agents, 1.68 hours, 3 sessions, 2 agents Second Life OSS 1.23.0.2166: 0 crashes from 0 agents, 0.07 hours, 1 sessions, 1 agents Our usage processing runs a few days behind as you can see. It's hard to know if we're getting substantially better data this week or not. Skimming through the crash logs, we still see the usual suspects: "http-texture branch viewer locks up and client must be killed, no crash report is generated" http://jira.secondlife.com/browse/VWR-13437 "Occasional crashes in OpenJPEG" https://jira.secondlife.com/browse/VWR-13511 "Curl crashers" https://jira.secondlife.com/browse/VWR-12952 This one looks new to me, though (on Linux): * [0] do_elfio_glibc_backtrace() o /Unknown:0 * [1] LLAppViewer::handleSyncViewerCrash() o /Unknown:0 * [2] LLApp::setError() o /Unknown:0 * [3] default_unix_signal_handler(int, siginfo*, void*) o /Unknown:0 * [4] LLError::crashAndLoop(std::string const&) o /Unknown:0 * [5] LLError::Log::flush(std::basic_ostringstream, std::allocator >*, LLError::CallSite const&) o /Unknown:0 * [6] LLViewerImage::doLoadedCallbacks() o /Unknown:0 * [7] LLViewerImageList::updateImages(float) o /Unknown:0 * [8] display(int, float, int, int) o /Unknown:0 * [9] LLAppViewer::mainLoop() o /Unknown:0 * [10] main o /Unknown:0 * [11] /lib32/libc.so.6(__libc_start_main+0xe5) [0xf66a9775] o /Unknown:0 * [12] __gxx_personality_v0@@CXXABI Rob From robla at lindenlab.com Thu May 21 12:31:12 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 21 May 2009 12:31:12 -0700 Subject: [sldev] Testing Snowglobe Message-ID: <4A15AC00.4050304@lindenlab.com> Hi everyone, We have a number of test plans here: https://wiki.secondlife.com/wiki/Category:Test_Scripts If we could be assured that all of these tests were run in each development cycle, we could feel pretty good that Snowglobe has been put through the paces. Is this an activity that people here would be interested in helping out with if we could figure out the right way to coordinate the activity (e.g. avoiding duplication of effort, giving guidance on priority of testing, etc) Additionally, for the new patches that come in, we have great test plans that it's not clear anyone other than probably the original developer ran through. See here for a great example: http://jira.secondlife.com/browse/VWR-8008 Of course, this may not be a necessary precondition to feeling good about a Snowglobe release. However, it seems like we should figure out a testing threshold that we need to clear before declaring a release "done" and moving on to the next release. What should that bar be? I'm going to add this to the agenda for the open source meeting later today (2pm PDT): http://jira.secondlife.com/browse/VWR-8008 Rob From robla at lindenlab.com Thu May 21 12:39:20 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 21 May 2009 12:39:20 -0700 Subject: [sldev] OSS meeting today (Re: Testing Snowglobe) In-Reply-To: <4A15AC00.4050304@lindenlab.com> References: <4A15AC00.4050304@lindenlab.com> Message-ID: <4A15ADE8.8030404@lindenlab.com> On 05/21/2009 12:31 PM, Rob Lanphier wrote: > I'm going to add this to the agenda for the open source meeting later > today (2pm PDT): > http://jira.secondlife.com/browse/VWR-8008 > Here's the URL I meant to link to: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Rob From philip at lindenlab.com Thu May 21 12:40:05 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Thu, 21 May 2009 12:40:05 -0700 Subject: [sldev] Closing out the merge window In-Reply-To: <4A159952.5000609@watson.ibm.com> References: <4A1463BF.2030802@lindenlab.com> <4A14893C.7030902@watson.ibm.com> <8475573D-BB08-4B99-AC10-7D3D5E98F341@gmail.com> <4A1578A4.8080307@watson.ibm.com> <4A15917E.9030103@superliminal.com> <4A159952.5000609@watson.ibm.com> Message-ID: <4A15AE15.7050604@lindenlab.com> One thing to keep in mind is that the release process that we are talking about will result in a snowglobe build which is made available to people on secondlife.com/download, which is a much larger (hopefully) audience than has ever used an open source Second Life build before. Hence the desire to make reasonably sure it is stable and safe. P Mike Monkowski wrote: > Melinda Green wrote: > >> That's a great question. Even though in theory this could be a >> continuous release process, there are some practical reasons to do it in >> cycles. The main reason is that during the normal phase where features >> are added and changed, we will naturally introduce bugs that tend to >> accumulate over time. The stabilization phases bring the bug levels down >> to acceptable levels. If it ever turned out code quality stayed high >> enough throughout development then you could make a great case for >> skipping this bit of protocol but I doubt that will ever happen and I >> think that's OK. >> > > You're working from a paradigm different from any that I have known. To > say, "that during the normal phase where features are added and changed, > we will naturally introduce bugs that tend to accumulate over time" is > astounding to me. Who lets bugs accumulate over time? > > If you assume that you're going to start with dirty code and hope to > clean it up when you get a chance, you're kidding yourself. You should > start with clean, well reviewed code and expect bugs caused by > interactions to be fixed over time. If you tolerate junk, you'll get junk. > > >> Another good reason for having release cycles is so that other parties >> can plan around them. One such party is LL who will want to cherry-pick >> from highly stable versions in order to inherit the fewest bugs in the >> process. Another party is the casual user who will only be willing to >> upgrade occasionally and will want to know which versions to grab. Yet >> another party is you! :-) Your private branch or copy that you work in >> will drift from the main Snowglobe branch and if your do a substantial >> (i.e. destabilizing) amount of work, you will want to merge approved >> changes back to Snowglobe when it is in a most stable phase so that the >> problems you introduce are most easily fixed. Even if you only intend to >> make small, infrequent changes, you will want to do that work when >> Snowglobe is most stable. >> > > Snowglobe is alpha code. It's not a competitor to the production > viewer. Each new feature will stabilize over time, but there's no need > to stabilize the entire set of features, because the entire set will > never be merged at once into the production viewer. You're not pulling > files from Snowglobe, you're just pulling the changesets. > > If you want stablity, you work with the production viewer source, not > Snowglobe. Any way you do it, you'll have to eventually merge back into > code that's constantly changing. > > If Snowglobe is ever stable, it means people no longer are contributing. > > >> I don't think that having a release cycle fragments a product. It simply >> regularizes the natural ebb and flow of quality and lets people plan >> around it. It's fine if we decide that Snowglobe's quality does not need >> to be as high as the main LL viewer (at the points where *its* quality >> is highest in its cycle). We just need to decide what our quality >> standard should be and then adjust the length of our stabilization >> phases in order to hit that target. >> > > I meant that it fragmented the audience of alpha testers. If you accept > an ebb and flow of quality, be prepared for more ebb than flow. The > standard should be "clean in," because the alternative is "garbage in; > garbage out." > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090521/78e6affc/attachment.htm From philip at lindenlab.com Thu May 21 12:42:52 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Thu, 21 May 2009 12:42:52 -0700 Subject: [sldev] Anyone here with OpenCV experience? Message-ID: <4A15AEBC.7070800@lindenlab.com> Has anyone here worked with camera-based gesture recognition before? How about OpenCV? Is OpenCV the best package for extracting basic head position/gesture information from a camera image stream? Merov and I are pondering a Snowglobe project to detect head motion from simple cameras and connect it to the SL Viewer. From dahliatrimble at gmail.com Thu May 21 12:51:39 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 21 May 2009 12:51:39 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15AEBC.7070800@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> Message-ID: I've done a fair bit of machine vision and object recognition work in the past but nothing specifically related to facial gesture recognition On Thu, May 21, 2009 at 12:42 PM, Philip Rosedale wrote: > Has anyone here worked with camera-based gesture recognition before? > How about OpenCV? Is OpenCV the best package for extracting basic head > position/gesture information from a camera image stream? Merov and I > are pondering a Snowglobe project to detect head motion from simple > cameras and connect it to the SL 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090521/610c1f87/attachment.htm From jan.ciger at gmail.com Thu May 21 13:04:49 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Thu, 21 May 2009 22:04:49 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15AEBC.7070800@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> Message-ID: <4A15B3E1.90604@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philip Rosedale wrote: > Has anyone here worked with camera-based gesture recognition before? > How about OpenCV? Is OpenCV the best package for extracting basic head > position/gesture information from a camera image stream? Merov and I > are pondering a Snowglobe project to detect head motion from simple > cameras and connect it to the SL Viewer. I have done something like that. First of all, OpenCV is does not do any gesture recognition. It is an image processing library and you need to know quite a bit about computer vision to be able to use it meaningfully. I have found this book indispensable for that: http://oreilly.com/catalog/9780596516130/ , plus a good basic computer vision textbook. If you want to track the orientation of the head with a webcam, that is doable - NaturalPoint is selling infrared webcams that track either a single point or a simple rig on your head and translate that to mouse motion. That is easy enough to do. If that is all you want to do (translate head motion to 2DOF mouse-like signal), OpenCV is even an overkill - capture image, threshold it to extract the marker and measure where it is compared to the initial position. Then use that difference to steer camera. The main issue you will have will be a cross-platform video capture library. I have yet to find one that is not too buggy and actually works without doing crazy stuff. OpenCV has some code for capturing video, but that is mainly for debugging and shouldn't be used for production (it is *really* buggy and slow). On the other hand, if you want to do something more complex - e.g. full 6DOF tracking, OpenCV is a good starting point. For example, I have the Minoru 3D webcam (http://www.minoru3d.com/) connected to a 3D tracker on Linux that allows me to track both the position and orientation in space - - like a 3D mouse. The tracker is made using OpenCV. However, calibrating that is not something for an average Joe to do ... Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFbPZn11XseNj94gRAmdkAJ9fbD8bpCVqK3KtJ1FTunFVSmVMTgCfRuvB VABbYQzKrgfLkcCI8i8iclk= =kMun -----END PGP SIGNATURE----- From dzonatas at gmail.com Thu May 21 13:35:50 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 21 May 2009 13:35:50 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15B3E1.90604@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> Message-ID: <4A15BB26.6040507@gmail.com> Jan Ciger wrote: > On the other hand, if you want to do something more complex - e.g. full > 6DOF tracking, OpenCV is a good starting point. For example, I have the > Minoru 3D webcam (http://www.minoru3d.com/) connected to a 3D tracker on > Linux that allows me to track both the position and orientation in space > - - like a 3D mouse. The tracker is made using OpenCV. However, > calibrating that is not something for an average Joe to do ... > > If you are going to consider something beyond a normal webcam, then do take a look at this: Head Tracking for Desktop VR Displays using the WiiRemote http://www.youtube.com/watch?v=Jd3-eiid-Uw (might have been posted on this list awhile ago?) I can just imagine head tracking like in that video but with HD displays on each side. Major immersion! From philip at lindenlab.com Thu May 21 13:22:02 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Thu, 21 May 2009 13:22:02 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15B3E1.90604@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> Message-ID: <4A15B7EA.70907@lindenlab.com> Have you seen this video... http://www.youtube.com/watch?v=r7Gn2TyEyHw It is a cheap logitech camera tracking a head and head rotation really well (which you can see by the registration quality of the video overlay). This is what we want - simple head position and movement tracking from a camera. I suppose we could just use the logitech API but that would restrict us to their cameras. I believe that the code they ship with their cameras is based on OpenCV? Hence the question. Philip Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Philip Rosedale wrote: > >> Has anyone here worked with camera-based gesture recognition before? >> How about OpenCV? Is OpenCV the best package for extracting basic head >> position/gesture information from a camera image stream? Merov and I >> are pondering a Snowglobe project to detect head motion from simple >> cameras and connect it to the SL Viewer. >> > > I have done something like that. First of all, OpenCV is does not do any > gesture recognition. It is an image processing library and you need to > know quite a bit about computer vision to be able to use it > meaningfully. I have found this book indispensable for that: > http://oreilly.com/catalog/9780596516130/ , plus a good basic computer > vision textbook. > > If you want to track the orientation of the head with a webcam, that is > doable - NaturalPoint is selling infrared webcams that track either a > single point or a simple rig on your head and translate that to mouse > motion. That is easy enough to do. If that is all you want to do > (translate head motion to 2DOF mouse-like signal), OpenCV is even an > overkill - capture image, threshold it to extract the marker and measure > where it is compared to the initial position. Then use that difference > to steer camera. > > The main issue you will have will be a cross-platform video capture > library. I have yet to find one that is not too buggy and actually works > without doing crazy stuff. OpenCV has some code for capturing video, but > that is mainly for debugging and shouldn't be used for production (it is > *really* buggy and slow). > > On the other hand, if you want to do something more complex - e.g. full > 6DOF tracking, OpenCV is a good starting point. For example, I have the > Minoru 3D webcam (http://www.minoru3d.com/) connected to a 3D tracker on > Linux that allows me to track both the position and orientation in space > - - like a 3D mouse. The tracker is made using OpenCV. However, > calibrating that is not something for an average Joe to do ... > > Regards, > > Jan > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFKFbPZn11XseNj94gRAmdkAJ9fbD8bpCVqK3KtJ1FTunFVSmVMTgCfRuvB > VABbYQzKrgfLkcCI8i8iclk= > =kMun > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090521/c7cc42c5/attachment.htm From jan.ciger at gmail.com Thu May 21 13:32:46 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Thu, 21 May 2009 22:32:46 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15BB26.6040507@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15BB26.6040507@gmail.com> Message-ID: <4A15BA6E.7060900@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dzonatas Sol wrote: > If you are going to consider something beyond a normal webcam, then do > take a look at this: > > Head Tracking for Desktop VR Displays using the WiiRemote > http://www.youtube.com/watch?v=Jd3-eiid-Uw > > (might have been posted on this list awhile ago?) > > I can just imagine head tracking like in that video but with HD displays > on each side. Major immersion! Except that nobody but a major geek will be able to set it up. Multiple screens, bluetooth, connecting Wiimote to Bluetooth, required calibration ... That something is using Wiimote doesn't mean it is working out of the box. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFbpun11XseNj94gRApkTAKCxEslaPShzCEJ5/goah4jc9bk/1ACfZRPO HBAarL0h+OOTQRwKcPKh2Ow= =GKAB -----END PGP SIGNATURE----- From tigrospottystripes at gmail.com Thu May 21 13:35:53 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 21 May 2009 17:35:53 -0300 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15B7EA.70907@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> Message-ID: <4A15BB29.1020401@Gmail.com> What about Freetrack ? http://www.free-track.net/english/ or you're going for more than just 6dof positioning, or positioning without anything but a webcam? Philip Rosedale escreveu: > Have you seen this video... http://www.youtube.com/watch?v=r7Gn2TyEyHw > > It is a cheap logitech camera tracking a head and head rotation really well (which you can see by the registration quality of the video overlay). > > This is what we want - simple head position and movement tracking from a camera. I suppose we could just use the logitech API but that would restrict us to their cameras. I believe that the code they ship with their cameras is based on OpenCV? Hence the question. > > Philip > > Jan Ciger wrote: > Philip Rosedale wrote: > > >>> Has anyone here worked with camera-based gesture recognition before? > >>> How about OpenCV? Is OpenCV the best package for extracting basic > head > >>> position/gesture information from a camera image stream? Merov and I > >>> are pondering a Snowglobe project to detect head motion from simple > >>> cameras and connect it to the SL Viewer. > >>> > > I have done something like that. First of all, OpenCV is does not do any > gesture recognition. It is an image processing library and you need to > know quite a bit about computer vision to be able to use it > meaningfully. I have found this book indispensable for that: > http://oreilly.com/catalog/9780596516130/ , plus a good basic computer > vision textbook. > > If you want to track the orientation of the head with a webcam, that is > doable - NaturalPoint is selling infrared webcams that track either a > single point or a simple rig on your head and translate that to mouse > motion. That is easy enough to do. If that is all you want to do > (translate head motion to 2DOF mouse-like signal), OpenCV is even an > overkill - capture image, threshold it to extract the marker and measure > where it is compared to the initial position. Then use that difference > to steer camera. > > The main issue you will have will be a cross-platform video capture > library. I have yet to find one that is not too buggy and actually works > without doing crazy stuff. OpenCV has some code for capturing video, but > that is mainly for debugging and shouldn't be used for production (it is > *really* buggy and slow). > > On the other hand, if you want to do something more complex - e.g. full > 6DOF tracking, OpenCV is a good starting point. For example, I have the > Minoru 3D webcam (http://www.minoru3d.com/) connected to a 3D tracker on > Linux that allows me to track both the position and orientation in space > - like a 3D mouse. The tracker is made using OpenCV. However, > calibrating that is not something for an average Joe to do ... > > Regards, > > Jan > > > ------------------------- > _______________________________________________ > 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 May 21 13:39:13 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 21 May 2009 13:39:13 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15B7EA.70907@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> Message-ID: I think the normal way to do something like that is known as "image correlation matching". Googling that phrase should provide some reference material. On Thu, May 21, 2009 at 1:22 PM, Philip Rosedale wrote: > Have you seen this video... http://www.youtube.com/watch?v=r7Gn2TyEyHw > > It is a cheap logitech camera tracking a head and head rotation really well > (which you can see by the registration quality of the video overlay). > > This is what we want - simple head position and movement tracking from a > camera. I suppose we could just use the logitech API but that would > restrict us to their cameras. I believe that the code they ship with their > cameras is based on OpenCV? Hence the question. > > Philip > > > Jan Ciger wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Philip Rosedale wrote: > > > Has anyone here worked with camera-based gesture recognition before? > How about OpenCV? Is OpenCV the best package for extracting basic head > position/gesture information from a camera image stream? Merov and I > are pondering a Snowglobe project to detect head motion from simple > cameras and connect it to the SL Viewer. > > > I have done something like that. First of all, OpenCV is does not do any > gesture recognition. It is an image processing library and you need to > know quite a bit about computer vision to be able to use it > meaningfully. I have found this book indispensable for that:http://oreilly.com/catalog/9780596516130/ , plus a good basic computer > vision textbook. > > If you want to track the orientation of the head with a webcam, that is > doable - NaturalPoint is selling infrared webcams that track either a > single point or a simple rig on your head and translate that to mouse > motion. That is easy enough to do. If that is all you want to do > (translate head motion to 2DOF mouse-like signal), OpenCV is even an > overkill - capture image, threshold it to extract the marker and measure > where it is compared to the initial position. Then use that difference > to steer camera. > > The main issue you will have will be a cross-platform video capture > library. I have yet to find one that is not too buggy and actually works > without doing crazy stuff. OpenCV has some code for capturing video, but > that is mainly for debugging and shouldn't be used for production (it is > *really* buggy and slow). > > On the other hand, if you want to do something more complex - e.g. full > 6DOF tracking, OpenCV is a good starting point. For example, I have the > Minoru 3D webcam (http://www.minoru3d.com/) connected to a 3D tracker on > Linux that allows me to track both the position and orientation in space > - - like a 3D mouse. The tracker is made using OpenCV. However, > calibrating that is not something for an average Joe to do ... > > Regards, > > Jan > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFKFbPZn11XseNj94gRAmdkAJ9fbD8bpCVqK3KtJ1FTunFVSmVMTgCfRuvB > VABbYQzKrgfLkcCI8i8iclk= > =kMun > -----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/20090521/d4036e00/attachment.htm From jan.ciger at gmail.com Thu May 21 13:43:17 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Thu, 21 May 2009 22:43:17 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15B7EA.70907@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> Message-ID: <4A15BCE5.5080206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philip Rosedale wrote: > Have you seen this video... http://www.youtube.com/watch?v=r7Gn2TyEyHw > > It is a cheap logitech camera tracking a head and head rotation really > well (which you can see by the registration quality of the video overlay). > > This is what we want - simple head position and movement tracking from a > camera. I suppose we could just use the logitech API but that would > restrict us to their cameras. I believe that the code they ship with > their cameras is based on OpenCV? Hence the question. I do not know if the code is based on OpenCV (probably not - license and all), but this is quite easy to do. Most likely they are using the well known CamShift algorithm for face tracking. Paper: http://download.intel.com/technology/itj/q21998/pdf/camshift.pdf US. Patent: http://www.google.com/patents?hl=en&lr=&vid=USPATAPP9079917&id=kaWEAAAAEBAJ&oi=fnd&dq=bradski+camshift Camshift gives you an orientation angle of the face elipsoid + 2D position + relative size that you can use to judge distance. OpenCV implements this algorithm (Gary Bradski is one of the main authors of OpenCV). I was using it before for simple tracking and it works reasonably well if you have good lighting conditions. It is fairly easy to use - there is actually a working example of it in OpenCV for face tracking. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFbzln11XseNj94gRAgqNAJwKnSe+0bP1T9ZKelLsqPclk/i00wCg1hHb +xP2lvS1ZflURARMNdYEe2o= =fVCu -----END PGP SIGNATURE----- From jan.ciger at gmail.com Thu May 21 13:45:50 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Thu, 21 May 2009 22:45:50 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> Message-ID: <4A15BD7E.3070400@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dahlia Trimble wrote: > I think the normal way to do something like that is known as "image > correlation matching". Googling that phrase should provide some > reference material. > That is a bit of an overkill for this application, Dahlia. Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFb1+n11XseNj94gRAoIfAJ4kmchCjy9F8toGt9IKP8AlAkbjVACgoqjZ OLiuuRSRC1Wvq+kEmTRStPs= =A+JD -----END PGP SIGNATURE----- From jan.ciger at gmail.com Thu May 21 13:47:33 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Thu, 21 May 2009 22:47:33 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15BB29.1020401@Gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> Message-ID: <4A15BDE5.8030805@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tigro Spottystripes wrote: > What about Freetrack ? http://www.free-track.net/english/ > > or you're going for more than just 6dof positioning, or positioning > without anything but a webcam? > It is not cross-platform (Windows only) and requires a marker rig to be worn. That is too complicated for simple camera movement. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFb3ln11XseNj94gRAojEAJ9T2sq1+x/HrQjpSWVTK6KwAadMsQCgkMtO v9MQmDFfPKWTJzz4vL53NRY= =KWi6 -----END PGP SIGNATURE----- From jan.ciger at gmail.com Thu May 21 13:49:27 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Thu, 21 May 2009 22:49:27 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15B7EA.70907@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> Message-ID: <4A15BE57.9080706@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philip Rosedale wrote: > Have you seen this video... http://www.youtube.com/watch?v=r7Gn2TyEyHw > > It is a cheap logitech camera tracking a head and head rotation really > well (which you can see by the registration quality of the video overlay). > > This is what we want - simple head position and movement tracking from a > camera. I suppose we could just use the logitech API but that would > restrict us to their cameras. I believe that the code they ship with > their cameras is based on OpenCV? Hence the question. > > Philip Another thing I have realized - if you want to track left-right rotation (as opposed to tilting the head or translating it), you could use some optic flow based algorithm. Again, there is a plenty of that. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFb5Xn11XseNj94gRAoAhAJwPA+3ZkzeRv6lrYFRTjbea/fsO3QCfWYzd HDBTEO8OtGWYmuiMlkWhmkQ= =QJdp -----END PGP SIGNATURE----- From jan.ciger at gmail.com Thu May 21 13:58:36 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Thu, 21 May 2009 22:58:36 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15B7EA.70907@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> Message-ID: <4A15C07C.9070207@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philip Rosedale wrote: > Have you seen this video... http://www.youtube.com/watch?v=r7Gn2TyEyHw > One more practical idea - I wouldn't integrate this kind of functionality in the viewer directly. That would be a mess to maintain with all the dependencies. Rather provide an interface e.g. via shared memory, RPC or whatever to access the camera matrix and the avatar controls from outside. Then these kind of useful hacks can be maintained outside of the viewer. I have used the tracker I have mentioned before with joystick emulation to drive SL viewer - without having to modify the viewer itself. Unfortunately the joystick interface is pretty crummy in SL. If you want to support various VR applications, then the ideal choice would be VRPN support (http://www.cs.unc.edu/Research/vrpn/). That is a kind-of unwritten standard for interfacing to various input devices in VR field. The huge advantage is that your application doesn't need to know at all what is on the other side - a joystick, mouse, Space Navigator, full body motion capture, whatever - you are getting only position vectors, quaternions and button presses. It is very easy to work with. The library is even network transparent - that is not something useful for an average SL user, but it is a huge help if you are running things on large walls with multiple computers. So in the end you would ship an extra executable that will do e.g. the face tracking in the background and SL will use its output automatically. The user could even swap it for a joystick server while SL is running and SL would just carry on without any problems. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFcB8n11XseNj94gRAkFPAKDWjM+ysTisj0xH9ZsI75VAJG/X0QCgs00T hhdST/6Z1ikzKTcXu2TkCic= =0Is0 -----END PGP SIGNATURE----- From tigrospottystripes at gmail.com Thu May 21 13:59:08 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 21 May 2009 17:59:08 -0300 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15BDE5.8030805@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> Message-ID: <4A15C09C.5020806@Gmail.com> It's GPLed so it canbe ported, and that also means it can be modified to get the data of the markers from a different source, like acomputer vision algorithm like it's being discussed Jan Ciger escreveu: > Tigro Spottystripes wrote: > > What about Freetrack ? http://www.free-track.net/english/ > > > or you're going for more than just 6dof positioning, or positioning > > without anything but a webcam? > > > It is not cross-platform (Windows only) and requires a marker rig to be > worn. That is too complicated for simple camera movement. > > Regards, > > Jan From bishopj at bishopphillips.com Thu May 21 14:06:46 2009 From: bishopj at bishopphillips.com (Jonathan Bishop) Date: Fri, 22 May 2009 07:06:46 +1000 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15B7EA.70907@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> Message-ID: CrazyTalk from Reallusion for Skype does head and gesture tracking using a standard webcam if I remember correctly. It uses this data to replace your head with a toon's head in the skype video stream. I recall that it does a pretty fair job of it and it is so simple to set up that I can't remember the setup stage when I was testing it out a year or two ago. I think it is up to version 4 or 5 now. I am pretty certain (99%) that they use an in house library, but given it is (or at least used to be) shipped free with skype their must be a deal that can be done. I know they have a patent pending on some trick of mapping the 2D web cam image to a 3Dmesh I think it has Xplatform versions in the developmet kit, but not in the product release which I think uses DirectX - but I am not certain about that. I do remember reading something on their website about the Xplatform support - but that might just be that it was planned. So anyway, my point is that something of what the Phillip wants can clearly be done with a standard webcam, but whether it is the full bottle of gesture recognition is another matter. I am a bit scratchy on the details because I only played with it for about 2 hours a year or two ago. 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 From jan.ciger at gmail.com Thu May 21 14:03:19 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Thu, 21 May 2009 23:03:19 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15C09C.5020806@Gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15C09C.5020806@Gmail.com> Message-ID: <4A15C197.9090304@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tigro Spottystripes wrote: > It's GPLed so it canbe ported, and that also means it can be modified to > get the data of the markers from a different source, like acomputer > vision algorithm like it's being discussed Tigro, the whole point of using the markers is that the algorithm needs it. If you are going to replace that, you can as well use a different library. The markers are a fundamental thing there. The porting is difficult - not because of the computer vision part (that is just math) but because capturing video on Windows, Mac and Linux is completely different. That code is completely platform specific and complex - if you have to write your own, again you can as well use a different tool. Believe me, I had to write a few of these. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFcGXn11XseNj94gRAkWoAJ9wGo8jUVze6sIbVAEfQBgrKkUUyQCfTYOq 0xsg8tlTjMRIMUoS9TsOTSg= =oAVc -----END PGP SIGNATURE----- From tigrospottystripes at gmail.com Thu May 21 14:08:27 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 21 May 2009 18:08:27 -0300 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15C197.9090304@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15C09C.5020806@Gmail.com> <4A15C197.9090304@gmail.com> Message-ID: <4A15C2CB.6060502@Gmail.com> I'm talking about using the 6dof calculation algorithm, but inputing 3 or 4 dots that were acquired a different way, like say, the eyes and the nose identified by another algorithm Jan Ciger escreveu: > Tigro Spottystripes wrote: > > It's GPLed so it canbe ported, and that also means it can be modified to > > get the data of the markers from a different source, like acomputer > > vision algorithm like it's being discussed > > Tigro, the whole point of using the markers is that the algorithm needs > it. If you are going to replace that, you can as well use a different > library. The markers are a fundamental thing there. > > The porting is difficult - not because of the computer vision part (that > is just math) but because capturing video on Windows, Mac and Linux is > completely different. That code is completely platform specific and > complex - if you have to write your own, again you can as well use a > different tool. Believe me, I had to write a few of these. > > Regards, > > Jan From jan.ciger at gmail.com Thu May 21 14:25:41 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Thu, 21 May 2009 23:25:41 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15C2CB.6060502@Gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15C09C.5020806@Gmail.com> <4A15C197.9090304@gmail.com> <4A15C2CB.6060502@Gmail.com> Message-ID: <4A15C6D5.3030705@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tigro Spottystripes wrote: > I'm talking about using the 6dof calculation algorithm, but inputing 3 > or 4 dots that were acquired a different way, like say, the eyes and the > nose identified by another algorithm Yes? You probably do not realize that those points need to be in a specific spatial relationship. The original algorithm works by fitting a model of the rig with known size into the 2D image. If you change the size (everyone's face is different), it won't work anymore.So you cannot just feed arbitrary 4 points acquired from a different place. Otherwise you would need at least two cameras in a calibrated rig (like that Minoru webcam) to be able to track anything more that 2DOF. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFcbVn11XseNj94gRAmivAJ9jqxXhpD6c0xDpd+GkfaTD8LMAbQCgrb+w AzjIZbv14mClR3SsQnhQiW4= =DF8i -----END PGP SIGNATURE----- From tigrospottystripes at gmail.com Thu May 21 14:29:52 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 21 May 2009 18:29:52 -0300 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15C6D5.3030705@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15C09C.5020806@Gmail.com> <4A15C197.9090304@gmail.com> <4A15C2CB.6060502@Gmail.com> <4A15C6D5.3030705@gmail.com> Message-ID: <4A15C7D0.9090607@Gmail.com> from what i remember of an old version of that program, you can change the positions it expects to find the dots in 3d as long as you follow a simple rule (like for 4 dots they can't be coplanar, I'm not sure about the requirements for 3 dots), so a generic pattern for the position of things in the face should work with minimum calibration Jan Ciger escreveu: > Tigro Spottystripes wrote: > > I'm talking about using the 6dof calculation algorithm, but inputing 3 > > or 4 dots that were acquired a different way, like say, the eyes and the > > nose identified by another algorithm > > Yes? You probably do not realize that those points need to be in a > specific spatial relationship. The original algorithm works by fitting a > model of the rig with known size into the 2D image. If you change the > size (everyone's face is different), it won't work anymore.So you cannot > just feed arbitrary 4 points acquired from a different place. > > Otherwise you would need at least two cameras in a calibrated rig (like > that Minoru webcam) to be able to track anything more that 2DOF. > > Regards, > > Jan From moriz.gupte at gmail.com Thu May 21 14:36:31 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Thu, 21 May 2009 15:36:31 -0600 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15C7D0.9090607@Gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15C09C.5020806@Gmail.com> <4A15C197.9090304@gmail.com> <4A15C2CB.6060502@Gmail.com> <4A15C6D5.3030705@gmail.com> <4A15C7D0.9090607@Gmail.com> Message-ID: Hello, For non-immersive VR stuff, I have seen a few web cam applications that allows one to map trackers to control keys of a game ( http://www.camspace.com). I do not know if they share their API (I thought I saw their SDK ... just checked they do provide an evaluation copy.. and they even have a link for emulation authoring here http://wiki.camspace.com) and a Lua scripting reference. Are we still designing for folks sitting in front of the screen? Would eye tracking not be more appropriate rather than head tracking (head posn remains fixed most of time in my case)? Would a linear mapping of head movement into the virtual environment be useful in terms of informing peers about areas of interest of the person's head being tracked? Or are we more looking at head movements to drive avatar navigation, or camera position? Interesting usability issues to here resolve, having head control of anyone of these things will impact time to select and interact with targets unless additional modal controls are introduced. Head tracking and eyetracking is definitely *more* problematic than in immersive 3D. R *apologies if post got multiplied I had to repost because I used a name that is not acceptable to the list On Thu, May 21, 2009 at 3:29 PM, Tigro Spottystripes < tigrospottystripes at gmail.com> wrote: > from what i remember of an old version of that program, you can change > the positions it expects to find the dots in 3d as long as you follow a > simple rule (like for 4 dots they can't be coplanar, I'm not sure about > the requirements for 3 dots), so a generic pattern for the position of > things in the face should work with minimum calibration > > > Jan Ciger escreveu: > > Tigro Spottystripes wrote: > > > I'm talking about using the 6dof calculation algorithm, but inputing 3 > > > or 4 dots that were acquired a different way, like say, the eyes and > the > > > nose identified by another algorithm > > > > Yes? You probably do not realize that those points need to be in a > > specific spatial relationship. The original algorithm works by fitting a > > model of the rig with known size into the 2D image. If you change the > > size (everyone's face is different), it won't work anymore.So you cannot > > just feed arbitrary 4 points acquired from a different place. > > > > Otherwise you would need at least two cameras in a calibrated rig (like > > that Minoru webcam) to be able to track anything more that 2DOF. > > > > Regards, > > > > Jan > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090521/f5922921/attachment-0001.htm From missannotoole at yahoo.com Thu May 21 14:38:22 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu, 21 May 2009 14:38:22 -0700 (PDT) Subject: [sldev] Testing Snowglobe In-Reply-To: <4A15AC00.4050304@lindenlab.com> References: <4A15AC00.4050304@lindenlab.com> Message-ID: <773830.15517.qm@web59101.mail.re1.yahoo.com> I see this in the wiki: "Getting resources from any host (instead of just the LL asset server)" What happened to LL providing a layer of control and security and defense from malware and other "unexpected content" by way of proxying the content? ________________________________ From: Rob Lanphier To: Second Life Developer Mailing List Sent: Thursday, May 21, 2009 3:31:12 PM Subject: [sldev] Testing Snowglobe Hi everyone, We have a number of test plans here: https://wiki.secondlife.com/wiki/Category:Test_Scripts If we could be assured that all of these tests were run in each development cycle, we could feel pretty good that Snowglobe has been put through the paces. Is this an activity that people here would be interested in helping out with if we could figure out the right way to coordinate the activity (e.g. avoiding duplication of effort, giving guidance on priority of testing, etc) Additionally, for the new patches that come in, we have great test plans that it's not clear anyone other than probably the original developer ran through. See here for a great example: http://jira.secondlife.com/browse/VWR-8008 Of course, this may not be a necessary precondition to feeling good about a Snowglobe release. However, it seems like we should figure out a testing threshold that we need to clear before declaring a release "done" and moving on to the next release. What should that bar be? I'm going to add this to the agenda for the open source meeting later today (2pm PDT): http://jira.secondlife.com/browse/VWR-8008 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/20090521/a48e4689/attachment.htm From jan.ciger at gmail.com Thu May 21 14:41:00 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Thu, 21 May 2009 23:41:00 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15C07C.9070207@gmail.com> Message-ID: <4A15CA6C.9010109@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ramesh Ramloll wrote: > Hello, > For non-immersive VR stuff, I have seen a few web cam applications that > allows one to map trackers to control keys of a game > (http://www.camspace.com). I do not know if they share their API (I > thought I saw their SDK a while back). That isn't difficult to do, but it will be probably not very smooth, I am afraid. > Are we still designing for folks sitting in front of the screen? Would > eye tracking not be more appropriate rather than head tracking (head > posn remains fixed most of time in my case)? Strictly speaking yes, but it is much harder to do with a cheap, consumer grade equipment without requiring the user to wear something on their head (typically a camera and an infrared LED pointed at your eye). A regular 640x480 webcam at ~80cm from the user's face will see the eyes only few pixels wide. Trying to measure the gaze direction from that is next to impossible with any accuracy. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFcpsn11XseNj94gRAnVlAJsFMykR0PUENReZE2Ucz+FKM1tYNwCfRGGA P1MNF1cEIX/IkohNSbu4uw8= =aPK9 -----END PGP SIGNATURE----- From moriz.gupte at gmail.com Thu May 21 14:46:07 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Thu, 21 May 2009 15:46:07 -0600 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15CA6C.9010109@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15C07C.9070207@gmail.com> <4A15CA6C.9010109@gmail.com> Message-ID: True. I used ISCAN eye trackers and (desktop and mobile) versions and they are bulky. There are however a few recent efforts here http://www.cogain.org/eyetrackers/low-cost-eye-trackers that is aimed at low cost eye tracking using webcams http://www.inference.phy.cam.ac.uk/opengazer/ Ramesh On Thu, May 21, 2009 at 3:41 PM, Jan Ciger wrote: > Strictly speaking yes, but it is much harder to do with a cheap, > consumer grade equipment without requiring the user to wear something on > their head (typically a camera and an infrared LED pointed at your eye). > > A regular 640x480 webcam at ~80cm from the user's face will see the eyes > only few pixels wide. Trying to measure the gaze direction from that is > next to impossible with any accuracy. > -- Rameshsharma Ramloll PhD Research Assistant Professor Idaho State University, PocatelloTel: 208-282-5333 More info at http://tr.im/RRamloll -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090521/59778577/attachment.htm From carlo at alinoe.com Thu May 21 14:57:10 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 21 May 2009 23:57:10 +0200 Subject: [sldev] Crash stats from the past week In-Reply-To: <4A15A798.6020203@lindenlab.com> References: <4A15A798.6020203@lindenlab.com> Message-ID: <20090521215710.GA28204@alinoe.com> > This one looks new to me, though (on Linux): > > * [0] do_elfio_glibc_backtrace() > o /Unknown:0 > * [1] LLAppViewer::handleSyncViewerCrash() > o /Unknown:0 > * [2] LLApp::setError() > o /Unknown:0 > * [3] default_unix_signal_handler(int, siginfo*, void*) > o /Unknown:0 > * [4] LLError::crashAndLoop(std::string const&) > o /Unknown:0 > * [5] LLError::Log::flush(std::basic_ostringstream std::char_traits, std::allocator >*, LLError::CallSite > const&) > o /Unknown:0 > * [6] LLViewerImage::doLoadedCallbacks() > o /Unknown:0 > * [7] LLViewerImageList::updateImages(float) > o /Unknown:0 > * [8] display(int, float, int, int) > o /Unknown:0 > * [9] LLAppViewer::mainLoop() > o /Unknown:0 > * [10] main I saw this one once myself with 1.22.11 (on linux, thus) Unfortunately, I'm very often socially busy and just have to relog asap without time to investigate things :/ -- Carlo Wood From jan.ciger at gmail.com Thu May 21 15:19:31 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 22 May 2009 00:19:31 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15C07C.9070207@gmail.com> <4A15CA6C.9010109@gmail.com> Message-ID: <4A15D373.1070803@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Moriz Gupte wrote: > True. I used ISCAN eye trackers and (desktop and mobile) versions and > they are bulky. > There are however a few recent efforts here > http://www.cogain.org/eyetrackers/low-cost-eye-trackers > that is aimed at low cost eye tracking using webcams > http://www.inference.phy.cam.ac.uk/opengazer/ > Ramesh Interesting, I didn't know about this one. Good thing to bookmark! Thanks and regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFdNxn11XseNj94gRApDAAKDA3Rlb40wpmpMCG3xmabiu0XW5bQCg0RCP L1wICfuBjGMXROYfsG/xAaM= =U1gk -----END PGP SIGNATURE----- From dahliatrimble at gmail.com Thu May 21 15:37:41 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 21 May 2009 15:37:41 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15BDE5.8030805@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> Message-ID: Overkill? I'm not so sure. Consider the extreme variations in contrast that something like this would be exposed to out in the field. Lighting is uncontrolled and unpredictable. A major source of light on a user's face may well come from the image shown on the monitor, and may reflect off of the user's glasses. Facial features are variable and skin tone, eyebrow color, and other facial hair could further confuse any detection methods. Background lighting and objects other than the user could cause false detections. Also the camera could not be controlled, Could one reasonably expect users to purchase a standard webcam from a single vendor when many computers come with integrated webcams? Somehow I don't think simple methods demonstrated that in a lab environment will perform well at all given all these potential confounds in all user environments. Whatever is implemented would need to be subjected to extensive user testing if any kind of wide acceptance would be desired. On Thu, May 21, 2009 at 1:47 PM, Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tigro Spottystripes wrote: > > What about Freetrack ? http://www.free-track.net/english/ > > > > or you're going for more than just 6dof positioning, or positioning > > without anything but a webcam? > > > > It is not cross-platform (Windows only) and requires a marker rig to be > worn. That is too complicated for simple camera movement. > > Regards, > > Jan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFKFb3ln11XseNj94gRAojEAJ9T2sq1+x/HrQjpSWVTK6KwAadMsQCgkMtO > v9MQmDFfPKWTJzz4vL53NRY= > =KWi6 > -----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/20090521/7858fa18/attachment.htm From jan.ciger at gmail.com Thu May 21 15:57:06 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 22 May 2009 00:57:06 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> Message-ID: <4A15DC42.6060802@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dahlia Trimble wrote: > Overkill? I'm not so sure. Consider the extreme variations in contrast > that something like this would be exposed to out in the field. Lighting > is uncontrolled and unpredictable. A major source of light on a user's > face may well come from the image shown on the monitor, and may reflect > off of the user's glasses. Facial features are variable and skin tone, > eyebrow color, and other facial hair could further confuse any detection > methods. Background lighting and objects other than the user could cause > false detections. Also the camera could not be controlled, Could one > reasonably expect users to purchase a standard webcam from a single > vendor when many computers come with integrated webcams? No, but that isn't the point. It doesn't need to be 100% perfect and robust - even the Logitech's solution is not. And yes, actually most of the lighting in an average room is stable - and can be compensated for. For example, the paper I have sent the link to deals with the lighting issues by calibration - it takes a picture of a skin patch (your face) and uses that to create a model of your skin color. That compensates for all the skin and lighting issues, even lot of camera parameters. An actual application would probably build a background model too to make the detection more robust. Again, a rather simple task. > > Somehow I don't think simple methods demonstrated that in a lab > environment will perform well at all given all these potential confounds > in all user environments. Whatever is implemented would need to be > subjected to extensive user testing if any kind of wide acceptance would > be desired. Sony is doing a brisk business with their hugely popular EyeToy series that is using these simple algorithms that you believe do not work. Do I need to say more? Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFdxAn11XseNj94gRAioWAJ4xNh7wHz5RZiYvGmtKupkuIh+bBQCdGHih wvsn1lnJPRQPNBn+LCOe+iw= =72oW -----END PGP SIGNATURE----- From dahliatrimble at gmail.com Thu May 21 16:57:31 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 21 May 2009 16:57:31 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15DC42.6060802@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> Message-ID: I imagine time and testing will weed out the optimal solution. :) Best regards, -dahlia On Thu, May 21, 2009 at 3:57 PM, Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dahlia Trimble wrote: > > Overkill? I'm not so sure. Consider the extreme variations in contrast > > that something like this would be exposed to out in the field. Lighting > > is uncontrolled and unpredictable. A major source of light on a user's > > face may well come from the image shown on the monitor, and may reflect > > off of the user's glasses. Facial features are variable and skin tone, > > eyebrow color, and other facial hair could further confuse any detection > > methods. Background lighting and objects other than the user could cause > > false detections. Also the camera could not be controlled, Could one > > reasonably expect users to purchase a standard webcam from a single > > vendor when many computers come with integrated webcams? > > No, but that isn't the point. It doesn't need to be 100% perfect and > robust - even the Logitech's solution is not. And yes, actually most of > the lighting in an average room is stable - and can be compensated for. > For example, the paper I have sent the link to deals with the lighting > issues by calibration - it takes a picture of a skin patch (your face) > and uses that to create a model of your skin color. That compensates for > all the skin and lighting issues, even lot of camera parameters. > > An actual application would probably build a background model too to > make the detection more robust. Again, a rather simple task. > > > > > Somehow I don't think simple methods demonstrated that in a lab > > environment will perform well at all given all these potential confounds > > in all user environments. Whatever is implemented would need to be > > subjected to extensive user testing if any kind of wide acceptance would > > be desired. > > Sony is doing a brisk business with their hugely popular EyeToy series > that is using these simple algorithms that you believe do not work. Do I > need to say more? > > Regards, > > Jan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFKFdxAn11XseNj94gRAioWAJ4xNh7wHz5RZiYvGmtKupkuIh+bBQCdGHih > wvsn1lnJPRQPNBn+LCOe+iw= > =72oW > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090521/590ef4f3/attachment.htm From moriz.gupte at gmail.com Thu May 21 16:57:41 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Thu, 21 May 2009 17:57:41 -0600 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15DC42.6060802@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> Message-ID: And I think the Wii functioning perfectly out the box proved that such technologies may certainly become mainstream once variations due to environmental conditions are dealt with properly. I think calibration is the other thing that needs to be automatic (there are strategies for doing this), a possible algo for e.g. to automate eye tracker calibrations could use the info we know about reflex gaze behavior with respect to animated visual stimulus (this is an approach I once implemented because austistic kids were not expected to follow instructions before their gaze was tracked). Well it does not 'stictly eliminate' the calibration but it happens without the user noticing it and it can be pretty fast (10-15s for a single pass ...) next question is...the advantages for tracking movement needs to be really good to outweigh the various Usability issues that will creep in (does not mean we should not try though) On Thu, May 21, 2009 at 4:57 PM, Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dahlia Trimble wrote: > > Overkill? I'm not so sure. Consider the extreme variations in contrast > > that something like this would be exposed to out in the field. Lighting > > is uncontrolled and unpredictable. A major source of light on a user's > > face may well come from the image shown on the monitor, and may reflect > > off of the user's glasses. Facial features are variable and skin tone, > > eyebrow color, and other facial hair could further confuse any detection > > methods. Background lighting and objects other than the user could cause > > false detections. Also the camera could not be controlled, Could one > > reasonably expect users to purchase a standard webcam from a single > > vendor when many computers come with integrated webcams? > > No, but that isn't the point. It doesn't need to be 100% perfect and > robust - even the Logitech's solution is not. And yes, actually most of > the lighting in an average room is stable - and can be compensated for. > For example, the paper I have sent the link to deals with the lighting > issues by calibration - it takes a picture of a skin patch (your face) > and uses that to create a model of your skin color. That compensates for > all the skin and lighting issues, even lot of camera parameters. > > An actual application would probably build a background model too to > make the detection more robust. Again, a rather simple task. > > > > > Somehow I don't think simple methods demonstrated that in a lab > > environment will perform well at all given all these potential confounds > > in all user environments. Whatever is implemented would need to be > > subjected to extensive user testing if any kind of wide acceptance would > > be desired. > > Sony is doing a brisk business with their hugely popular EyeToy series > that is using these simple algorithms that you believe do not work. Do I > need to say more? > > Regards, > > Jan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFKFdxAn11XseNj94gRAioWAJ4xNh7wHz5RZiYvGmtKupkuIh+bBQCdGHih > wvsn1lnJPRQPNBn+LCOe+iw= > =72oW > -----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 > -- Rameshsharma Ramloll PhD Research Assistant Professor Idaho State University, PocatelloTel: 208-282-5333 More info at http://tr.im/RRamloll -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090521/9c29243e/attachment.htm From jan.ciger at gmail.com Thu May 21 17:29:15 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 22 May 2009 02:29:15 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> Message-ID: <4A15F1DB.2080705@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moriz Gupte wrote: > And I think the Wii functioning perfectly out the box proved that such > technologies may certainly become mainstream once variations due to > environmental conditions are dealt with properly. I think calibration is > the other thing that needs to be automatic (there are strategies for > doing this), a possible algo for e.g. to automate eye tracker > calibrations could use the info we know about reflex gaze behavior with > respect to animated visual stimulus (this is an approach I once > implemented because austistic kids were not expected to follow > instructions before their gaze was tracked). I wonder - how did you deal with the issue of having to hold the head still? Or did you track that as well? If the head moves, the whole gaze information is not valid unless the movement is tracked as well. We have done that before by combining a gaze tracker with a 6DOF magnetic tracker, but that is neither a lowcost nor practical solution for home user. But it was really robust, that is true. However, using gaze to control anything (camera, avatar, whatever) is extremely bad idea - it is really tiring and eye movement is not something people can consciously control. Someone speaks next to you and you turn your head reflexively - throwing the whole system for a loop. At best it could be used to determine what you are looking at passively and use that for either some kind of feedback, perceptually-enhanced rendering or just to make the av look at the same thing to improve the facial expressions for the others looking at you. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFfHWn11XseNj94gRApc3AKCygmkfVbIvfJqGkCnHYU+B7X5L2gCfUieL VBHomVn7/6tnhNYkX3i5DJg= =yDFJ -----END PGP SIGNATURE----- From moriz.gupte at gmail.com Thu May 21 17:54:13 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Thu, 21 May 2009 18:54:13 -0600 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15F1DB.2080705@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> Message-ID: > > I wonder - how did you deal with the issue of having to hold the head > still? Or did you track that as well? If the head moves, the whole gaze > information is not valid unless the movement is tracked as well. The clip here provides some answer. http://www.youtube.com/watch?v=nQDdgrgkqh4 Looking at it again, I had a (what was I thinking feeling-) wonder what the kids must have felt going into that...anyway.. But yes, the eye tracker had an inbuilt servo mechanism that tracked the head motion and moved the camera that was looking at the eye so that it would always be at the center. Of course, it just provides *some* opportunities for move the head a bit (you cannot go completely relaxed and move your head wildly...we used some seats that constrained to some extent head movement > > However, using gaze to control anything (camera, avatar, whatever) is > extremely bad idea - it is really tiring and eye movement is not > something people can consciously control. Someone speaks next to you and > you turn your head reflexively - throwing the whole system for a loop. > At best it could be used to determine what you are looking at passively > and use that for either some kind of feedback, perceptually-enhanced > rendering or just to make the av look at the same thing to improve the > facial expressions for the others looking at you. Right on. I am with you here. definitely gaze/head avatar navigation control is *very likely going to cause more problems* unless u are moving into the 'assistive technology' arena where the user has a mobility impairment. There is some wiggle room for cam control *I think*... I have some ideas...but just speculations at this stage. This whole head/gaze based UI is really a toughie... we need to design an intelligent enough system that would separate 'unconscious' reflexes from 'intentional ones'... that's a hard prob. > > > Regards, > > Jan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFKFfHWn11XseNj94gRApc3AKCygmkfVbIvfJqGkCnHYU+B7X5L2gCfUieL > VBHomVn7/6tnhNYkX3i5DJg= > =yDFJ > -----END PGP SIGNATURE----- > -- Rameshsharma Ramloll PhD Research Assistant Professor Idaho State University, PocatelloTel: 208-282-5333 More info at http://tr.im/RRamloll -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090521/f6946748/attachment.htm From open at autistici.org Thu May 21 18:12:14 2009 From: open at autistici.org (Opensource Obscure) Date: Fri, 22 May 2009 01:12:14 +0000 Subject: [sldev] Testing Snowglobe In-Reply-To: <4A15AC00.4050304@lindenlab.com> References: <4A15AC00.4050304@lindenlab.com> Message-ID: <0413542c5df56e13bf253fe917528d15@localhost> On Thu, 21 May 2009 12:31:12 -0700, Rob Lanphier wrote: > Hi everyone, > > We have a number of test plans here: > https://wiki.secondlife.com/wiki/Category:Test_Scripts > > If we could be assured that all of these tests were run in each > development cycle, we could feel pretty good that Snowglobe has been put > through the paces. Is this an activity that people here would be > interested in helping out with if we could figure out the right way to > coordinate the activity (e.g. avoiding duplication of effort, giving > guidance on priority of testing, etc) I'd be available to do some testing. For various reasons, I'd prefer to do those tests where 1 person only is needed. ciao, Opensource Obscure From stickman at gmail.com Thu May 21 18:56:21 2009 From: stickman at gmail.com (Stickman) Date: Thu, 21 May 2009 18:56:21 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> Message-ID: This is a huge thread for a feature I wouldn't use. But a friend recently picked up TrackIR. The site: http://www.naturalpoint.com/trackir/ A explanation: http://www.youtube.com/watch?v=_AO0F5sLdVM TrackIR in ArmA2 (WWII simulator): http://www.youtube.com/watch?v=9wXx3vMy_AQ Haven't read the thread -- don't know if it's useful. But it seems to be at least tangetally related, so I figured I'd mention it. -Stickman From moriz.gupte at gmail.com Thu May 21 19:10:23 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Thu, 21 May 2009 20:10:23 -0600 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> Message-ID: This is funny. You dont seem enthusiastic about it.. yet the clip you posted makes me want to buy the TrackIR [image: :)] Getting motion scaling right is key... man I did not think this would work so well ...at least the demo in the second clip is awesome. Thanks for clips. On Thu, May 21, 2009 at 7:56 PM, Stickman wrote: > This is a huge thread for a feature I wouldn't use. > > But a friend recently picked up TrackIR. > > The site: > http://www.naturalpoint.com/trackir/ > > A explanation: > http://www.youtube.com/watch?v=_AO0F5sLdVM > > TrackIR in ArmA2 (WWII simulator): > http://www.youtube.com/watch?v=9wXx3vMy_AQ > > Haven't read the thread -- don't know if it's useful. But it seems to > be at least tangetally related, so I figured I'd mention 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 > -- Rameshsharma Ramloll PhD Research Assistant Professor Idaho State University, PocatelloTel: 208-282-5333 More info at http://tr.im/RRamloll -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090521/193cb266/attachment.htm From jan.ciger at gmail.com Thu May 21 19:40:58 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 22 May 2009 04:40:58 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> Message-ID: <4A1610BA.5000405@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moriz Gupte wrote: > The clip here provides some answer. > http://www.youtube.com/watch?v=nQDdgrgkqh4 > Looking at it again, I had a (what was I thinking feeling-) wonder what > the kids must have felt going into that...anyway.. > But yes, the eye tracker had an inbuilt servo mechanism that tracked the > head motion and moved the camera that was looking at the eye so that it > would always be at the center. Of course, it just provides *some* > opportunities for move the head a bit (you cannot go completely relaxed > and move your head wildly...we used some seats that constrained to some > extent head movement Eew, what a contraption! Well, still better that the idea my former students had - they wanted to build literally a head "vice" to keep the user's head still :-p It is a pity I do not have the proposed sketch scanned, that was some piece of usability engineering right there :-p > Right on. I am with you here. definitely gaze/head avatar navigation > control is *very likely going to cause more problems* unless u are > moving into the 'assistive technology' arena where the user has a > mobility impairment. There is some wiggle room for cam control *I > think*... I have some ideas...but just speculations at this stage. This > whole head/gaze based UI is really a toughie... we need to design an > intelligent enough system that would separate 'unconscious' reflexes > from 'intentional ones'... that's a hard prob. We have tried some of this before, but it is extremely tiring - there is no "offline" or "relaxed" posture. As the system keeps tracking you all the time, it will always end up in a mess which is very frustrating for the user. Even for assistive purposes there are better solutions than pure gaze tracking (breath sensors, tongue controllers, EEG, EMG sensors ...). But we are getting off-topic here, I think :) Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFhC3n11XseNj94gRAgzPAKDkC5XFFfbMYJuVZFsACBQndQnR6ACffZde fEB7ryY66aeaQnt5eQaIA1k= =a2o8 -----END PGP SIGNATURE----- From tigrospottystripes at gmail.com Thu May 21 19:46:19 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 21 May 2009 23:46:19 -0300 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A1610BA.5000405@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B3E1.90604@gmail.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> <4A1610BA.5000405@gmail.com> Message-ID: <4A1611FB.4050203@Gmail.com> What about using headtracking in push-to-nod mode? :P in a few months LL will be reporting 1 million hours of tele-nodding served :P Jan Ciger escreveu: > Moriz Gupte wrote: > > The clip here provides some answer. > > http://www.youtube.com/watch?v=nQDdgrgkqh4 > > Looking at it again, I had a (what was I thinking feeling-) wonder what > > the kids must have felt going into that...anyway.. > > But yes, the eye tracker had an inbuilt servo mechanism that tracked the > > head motion and moved the camera that was looking at the eye so that it > > would always be at the center. Of course, it just provides *some* > > opportunities for move the head a bit (you cannot go completely relaxed > > and move your head wildly...we used some seats that constrained to some > > extent head movement > > Eew, what a contraption! Well, still better that the idea my former > students had - they wanted to build literally a head "vice" to keep the > user's head still :-p It is a pity I do not have the proposed sketch > scanned, that was some piece of usability engineering right there :-p > > > Right on. I am with you here. definitely gaze/head avatar navigation > > control is *very likely going to cause more problems* unless u are > > moving into the 'assistive technology' arena where the user has a > > mobility impairment. There is some wiggle room for cam control *I > > think*... I have some ideas...but just speculations at this stage. This > > whole head/gaze based UI is really a toughie... we need to design an > > intelligent enough system that would separate 'unconscious' reflexes > > from 'intentional ones'... that's a hard prob. > > We have tried some of this before, but it is extremely tiring - there is > no "offline" or "relaxed" posture. As the system keeps tracking you all > the time, it will always end up in a mess which is very frustrating for > the user. Even for assistive purposes there are better solutions than > pure gaze tracking (breath sensors, tongue controllers, EEG, EMG sensors > ...). > > But we are getting off-topic here, I think :) > > Regards, > > Jan _______________________________________________ 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 jan.ciger at gmail.com Thu May 21 19:51:23 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 22 May 2009 04:51:23 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> Message-ID: <4A16132B.2050009@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moriz Gupte wrote: > This is funny. You dont seem enthusiastic about it.. yet the clip you > posted makes me want to buy the TrackIR :) > Getting motion scaling right is key... man I did not think this would > work so well ...at least the demo in the second clip is awesome. Thanks > for clips. > We actually have several of the TrackIR devices in the lab. I think I have tried probably all versions of it (we have some special arrangements with Natural Point). In short - it works and it is quite robust, but do not expect miracles from it. If you are willing to wear a cap with a marker(s) or stick a reflective point to your forehead, it is OK. It doesn't like direct sunlight and reflective surfaces (e.g. glasses) which make false markers. It works either as a mouse emulator (turning your head moves the mouse cursor) - e.g. SL in mouselook could work with it without changes. Or you can develop your own app using their SDKs. The whole device is basically an USB infrared webcam + software, nothing else - essentially what Philip was asking for. There is a usability issue with it, though - if you turn your head to the left, for example, the image on the screen moves accordingly - however you probably do not see it any more because you are looking left of the screen. In the best case you are squinting back at the screen using your peripheral vision. These kind of devices work best if you have at least 180 degrees field of view covered (e.g. 3 screens/projectors in a U shape), a regular screen is not very natural with it. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFhMrn11XseNj94gRAo2UAKCo+3NXBe0BjQDQjmrJmU8RPGKDHgCfZGbY y7BHOR+CnyWXLjIw8kwilxY= =4f3E -----END PGP SIGNATURE----- From tigrospottystripes at gmail.com Thu May 21 19:54:15 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 21 May 2009 23:54:15 -0300 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A16132B.2050009@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> Message-ID: <4A1613D7.6020203@Gmail.com> I don't wanna sound like I'm promoting it nor anything, but I think you should give Freetrack a try, from what I've read it might allow for a better enjoyment of your TrackIR Jan Ciger escreveu: > Moriz Gupte wrote: > > This is funny. You dont seem enthusiastic about it.. yet the clip you > > posted makes me want to buy the TrackIR :) > > Getting motion scaling right is key... man I did not think this would > > work so well ...at least the demo in the second clip is awesome. Thanks > > for clips. > > > We actually have several of the TrackIR devices in the lab. I think I > have tried probably all versions of it (we have some special > arrangements with Natural Point). In short - it works and it is quite > robust, but do not expect miracles from it. If you are willing to wear a > cap with a marker(s) or stick a reflective point to your forehead, it is > OK. It doesn't like direct sunlight and reflective surfaces (e.g. > glasses) which make false markers. > > It works either as a mouse emulator (turning your head moves the mouse > cursor) - e.g. SL in mouselook could work with it without changes. Or > you can develop your own app using their SDKs. The whole device is > basically an USB infrared webcam + software, nothing else - essentially > what Philip was asking for. > > There is a usability issue with it, though - if you turn your head to > the left, for example, the image on the screen moves accordingly - > however you probably do not see it any more because you are looking left > of the screen. In the best case you are squinting back at the screen > using your peripheral vision. These kind of devices work best if you > have at least 180 degrees field of view covered (e.g. 3 > screens/projectors in a U shape), a regular screen is not very natural > with it. > > Regards, > > Jan > _______________________________________________ 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 jan.ciger at gmail.com Thu May 21 20:06:15 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 22 May 2009 05:06:15 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A1613D7.6020203@Gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> Message-ID: <4A1616A7.4090002@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tigro Spottystripes wrote: > I don't wanna sound like I'm promoting it nor anything, but I think you > should give Freetrack a try, from what I've read it might allow for a > better enjoyment of your TrackIR It doesn't do anything more than the stock software on the TrackIR camera. And oh yes: > Natural Point? requested us to remove Track-IR? cameras support from FreeTrack. So it even doesn't work with it. I guess they were using the SDK which has a rather restrictive license, so Natural Point has shut them down. Their cameras use proprietary protocol (how nice! :( ), so there is not much they can do. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFhann11XseNj94gRAnIvAJ0bNDg2Iakdzdc/dJ6plkOgRZlefwCg7oHI +boLrhmYxrQp9sbHXW0PWDk= =OBmX -----END PGP SIGNATURE----- From dahliatrimble at gmail.com Thu May 21 20:08:24 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 21 May 2009 20:08:24 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A1613D7.6020203@Gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> Message-ID: Freetrack looks interesting and it would seem that using LEDs might help with some of the potential environmental problems. Looks like it's GPLv2 so it may be usable with an open source viewer, but could it be licensed under the LL contributor agreement as well? Perhaps with all of these options available it may be worthwhile to consider some kind of universal interface and let the user connect up whatever hardware they choose. On Thu, May 21, 2009 at 7:54 PM, Tigro Spottystripes < tigrospottystripes at gmail.com> wrote: > I don't wanna sound like I'm promoting it nor anything, but I think you > should give Freetrack a try, from what I've read it might allow for a > better enjoyment of your TrackIR > > Jan Ciger escreveu: > > Moriz Gupte wrote: > > > This is funny. You dont seem enthusiastic about it.. yet the clip you > > > posted makes me want to buy the TrackIR :) > > > Getting motion scaling right is key... man I did not think this would > > > work so well ...at least the demo in the second clip is awesome. Thanks > > > for clips. > > > > > > We actually have several of the TrackIR devices in the lab. I think I > > have tried probably all versions of it (we have some special > > arrangements with Natural Point). In short - it works and it is quite > > robust, but do not expect miracles from it. If you are willing to wear a > > cap with a marker(s) or stick a reflective point to your forehead, it is > > OK. It doesn't like direct sunlight and reflective surfaces (e.g. > > glasses) which make false markers. > > > > It works either as a mouse emulator (turning your head moves the mouse > > cursor) - e.g. SL in mouselook could work with it without changes. Or > > you can develop your own app using their SDKs. The whole device is > > basically an USB infrared webcam + software, nothing else - essentially > > what Philip was asking for. > > > > There is a usability issue with it, though - if you turn your head to > > the left, for example, the image on the screen moves accordingly - > > however you probably do not see it any more because you are looking left > > of the screen. In the best case you are squinting back at the screen > > using your peripheral vision. These kind of devices work best if you > > have at least 180 degrees field of view covered (e.g. 3 > > screens/projectors in a U shape), a regular screen is not very natural > > with it. > > > > Regards, > > > > Jan > > > _______________________________________________ > 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/20090521/aeb2ca27/attachment-0001.htm From dzonatas at gmail.com Thu May 21 20:44:21 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 21 May 2009 20:44:21 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15AEBC.7070800@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> Message-ID: <4A161F95.6090804@gmail.com> After I read all the great replies on this list that this question has generated, I think there may be a way to allow several options and LL wouldn't have to be stuck with only one single driver. LL just needs to agree upon a generic interface that is needed to control head motion, mouth, common gestures and such. Let the community work together with LL to design any implementation from there. Anotherwords, build towards the generic interface instead of towards the driver itself. It's actually an old development principle. What are the needed methods for the generic interface? * Head Yaw * Head Pitch * Head Roll Left & Right Versions: * Eyelid Blink * Eyelid Close * Eyelid Open * Eyelid Pitch Left & Right Versions: * Eyebrow Pitch * Eyebrow Roll * Mouth... Sure there will be many for the mouth. Upon an event to trigger a head gesture, find and play the animations that best match the criteria passed by the generic interface. Again, there seems several really good suggestion made on this list, so this suggestion for a generic interface is one way to allow the user to use any of them. *wink* Philip Rosedale wrote: > Has anyone here worked with camera-based gesture recognition before? > How about OpenCV? Is OpenCV the best package for extracting basic head > position/gesture information from a camera image stream? Merov and I > are pondering a Snowglobe project to detect head motion from simple > cameras and connect it to the SL 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 > > From jan.ciger at gmail.com Thu May 21 20:29:59 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 22 May 2009 05:29:59 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> Message-ID: <4A161C37.20002@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dahlia Trimble wrote: > Freetrack looks interesting and it would seem that using LEDs might help > with some of the potential environmental problems. Looks like it's GPLv2 > so it may be usable with an open source viewer, but could it be licensed > under the LL contributor agreement as well? > > Perhaps with all of these options available it may be worthwhile to > consider some kind of universal interface and let the user connect up > whatever hardware they choose. That is why I was proposing VRPN for these kind of devices. FreeTrack is Windows-only despite being GPL - most likely because of the video capture code. It would then be trivial to interface basically anything to SL, if the viewer would take camera matrix and allow avatar control from outside. And Lindens wouldn't have to maintain the device specific stuff neither. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFhw3n11XseNj94gRAvpqAKDc+qRGOXmbMfZ5Kwqukqdimd1uqgCg6Rfz YAq6diULiVvt5Bb4EPpFQmY= =0R9j -----END PGP SIGNATURE----- From robla at lindenlab.com Thu May 21 20:32:32 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 21 May 2009 20:32:32 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15AEBC.7070800@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> Message-ID: <4A161CD0.7020600@lindenlab.com> On 05/21/2009 12:42 PM, Philip Rosedale wrote: > Has anyone here worked with camera-based gesture recognition before? > How about OpenCV? Is OpenCV the best package for extracting basic head > position/gesture information from a camera image stream? Merov and I > are pondering a Snowglobe project to detect head motion from simple > cameras and connect it to the SL Viewer This thread has certainly generated a lot of interest. Any volunteers to summarize the information from this thread on the wiki? https://wiki.secondlife.com/wiki/Camera-based_gesture_recognition Rob From tigrospottystripes at gmail.com Thu May 21 20:35:53 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 22 May 2009 00:35:53 -0300 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A1616A7.4090002@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> <4A1616A7.4090002@gmail.com> Message-ID: <4A161D99.5010200@Gmail.com> according to Wikipedia: "At NaturalPoint's request, FreeTrack project members removed the strings from the software they provide to end users. FreeTrack then implemented a workaround which creates a local copy of these strings from the client software when used with TrackIR Enhanced titles. FreeTrack project members argue that copyright is not violated in this case since it may fall under the provision of 17 U.S.C. ? 117 " Though it then follows mentioning that more recent versions of the TrackIR software uses encryption to communicate with games and such to try to kick Freetrack out of the way again, but there are workarounds to make some of the new programs be compatible with Freetrack again. I have no experience with TrackIR's own programs, but you mentioned that you can't look left without having the monitor be out of your field of view, Freetrack can map all the axis, so you can look left without having to use mirrors to ses the monitor, you can actually look 180 degrees or more without ever moving anything bellow the neck and still keep the monitor in plain sight easily, hell, you can look to the bottom of the screen and have the view go past showing your avatar feet and seeing what is behind you upside down :P ps:extreme pitch angles tend to be restricted in many engines, either for arbitrary reasons or for technical ones, like gimbal lock and such) Jan Ciger escreveu: > > Natural Point" requested us to remove Track-IR" cameras support from > FreeTrack. > > So it even doesn't work with it. I guess they were using the SDK which > has a rather restrictive license, so Natural Point has shut them down. > Their cameras use proprietary protocol (how nice! :( ), so there is not > much they can do. > > Regards, > > Jan From tigrospottystripes at gmail.com Thu May 21 20:52:07 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 22 May 2009 00:52:07 -0300 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A1616A7.4090002@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> <4A1616A7.4090002@gmail.com> Message-ID: <4A162167.1080207@Gmail.com> (resending because I didn't got the confirmation msg from the list after I sent this the first time) according to Wikipedia: "At NaturalPoint's request, FreeTrack project members removed the strings from the software they provide to end users. FreeTrack then implemented a workaround which creates a local copy of these strings from the client software when used with TrackIR Enhanced titles. FreeTrack project members argue that copyright is not violated in this case since it may fall under the provision of 17 U.S.C. ? 117 " Though it then follows mentioning that more recent versions of the TrackIR software uses encryption to communicate with games and such to try to kick Freetrack out of the way again, but there are workarounds to make some of the new programs be compatible with Freetrack again. I have no experience with TrackIR's own programs, but you mentioned that you can't look left without having the monitor be out of your field of view, Freetrack can map all the axis, so you can look left without having to use mirrors to see the monitor, you can actually look 180 degrees or more without ever moving anything bellow the neck and still keep the monitor in plain sight easily, hell, you can look to the bottom of the screen and have the view go past showing your avatar feet and seeing what is behind you upside down :P ps:extreme pitch angles tend to be restricted in many engines, either for arbitrary reasons or for technical ones, like gimbal lock and such) Jan Ciger escreveu: > > Natural Point" requested us to remove Track-IR" cameras support from > FreeTrack. > > So it even doesn't work with it. I guess they were using the SDK which > has a rather restrictive license, so Natural Point has shut them down. > Their cameras use proprietary protocol (how nice! :( ), so there is not > much they can do. > > Regards, > > Jan From tigrospottystripes at gmail.com Thu May 21 21:06:26 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 22 May 2009 01:06:26 -0300 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A161F95.6090804@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A161F95.6090804@gmail.com> Message-ID: <4A1624C2.90404@Gmail.com> how about making it even more generalized and allow any input to move anything, like for example, we could put 3 axis of a VR glove to one hand using the IK, perhaps like how it happens when a selected object is in the arm's reach), the analog or digital inputs of the fingers would trigger the corresponding hand position morph, some axis of another source control certain face morphs, others may move the feet, another set move the hips (with IK so the hands and feet stay where they're supposed to), then perhaps, a different device to control actual motion of the avatar, another for the third person camera and so on for face recognition from video, we can use "virtual" devices, which have axis corresponding the the measured parameters in the video, this way, if someone for example wanna use a MIDI or OSC device/source to better tweak facial expressions, like for machinima, it is also possible and the client won't care what the source is, it just reads the values and applies to the mapped property of the avatar (I don't think I would need to include another example, but with this someone could use a VR glove to make their av's head and mouth work in the classic analog sockpuppet style) ps:a while ago I pictured a way to make an avatar do the complete Macarena choreography in real time using a right hand VR glove and different keypresses to change on the fly which parts where controled by the glove and how, I'll see if eventually I'll write it down and post it on Jira Dzonatas Sol escreveu: > After I read all the great replies on this list that this question has > generated, I think there may be a way to allow several options and LL > wouldn't have to be stuck with only one single driver. > > LL just needs to agree upon a generic interface that is needed to > control head motion, mouth, common gestures and such. Let the community > work together with LL to design any implementation from there. > Anotherwords, build towards the generic interface instead of towards the > driver itself. It's actually an old development principle. > > What are the needed methods for the generic interface? > > * Head Yaw > * Head Pitch > * Head Roll > > Left & Right Versions: > * Eyelid Blink > * Eyelid Close > * Eyelid Open > * Eyelid Pitch > > Left & Right Versions: > * Eyebrow Pitch > * Eyebrow Roll > > * Mouth... > > Sure there will be many for the mouth. > > Upon an event to trigger a head gesture, find and play the animations > that best match the criteria passed by the generic interface. > > Again, there seems several really good suggestion made on this list, so > this suggestion for a generic interface is one way to allow the user to > use any of them. *wink* > > Philip Rosedale wrote: > >> Has anyone here worked with camera-based gesture recognition before? >> How about OpenCV? Is OpenCV the best package for extracting basic head >> position/gesture information from a camera image stream? Merov and I >> are pondering a Snowglobe project to detect head motion from simple >> cameras and connect it to the SL 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 >> >> >> > > _______________________________________________ > 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 Celierra at gmail.com Thu May 21 21:14:39 2009 From: Celierra at gmail.com (Celierra Darling) Date: Fri, 22 May 2009 00:14:39 -0400 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> Message-ID: I think we could be getting way way ahead of ourselves here. Before judging whether this or that library is good, what exactly is the application(s) being discussed? There seems to be a bunch of multiple takes on things. The one I was personally expecting at the start of the thread was the thing that was dicussed once before [1] -- something like Johnny Lee's Wiimote hack [2], but without the Wiimote hack. For such an application, it's not obvious to me that there's a need for detection of, say, pitch, yaw, or roll, other than maybe being robust to their presence. (For example, if you roll your head, both the in-world camera and your real-world head are already rotating -- so why should the orientation of the world change with respect to the orientation of the screen? It's not like the screen is moving along with your head.) Something pretty basic would probably be okay. Another take seems to be like treating movements like generic gestures and mapping them to commands or controls with less constraint. Something like TrackIR seems to try to exaggerate all the motions, even stuff like roll. Yet another take includes mouth and eye movements, etc. like that Logitech demo. I agree that this would be very nice, but this seems like it'd need server-side support too to be useful, and maybe it's outside the scope of what was intended.... I think we need to settle on our expectations before figuring out which libraries are best. [1] https://lists.secondlife.com/pipermail/sldev/2008-September/011863.html [2] http://www.youtube.com/watch?v=Jd3-eiid-Uw Celi On Thu, May 21, 2009 at 9:56 PM, Stickman wrote: > This is a huge thread for a feature I wouldn't use.... > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090522/345698c3/attachment.htm From tigrospottystripes at gmail.com Thu May 21 21:24:52 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 22 May 2009 01:24:52 -0300 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> Message-ID: <4A162914.5080105@Gmail.com> perhaps instead of discarding the stuff that went a bit off topic, wouldn't it be better to branch the conversation instead? Celierra Darling escreveu: > I think we could be getting way way ahead of ourselves here. Before > judging whether this or that library is good, what exactly is the > application(s) being discussed? There seems to be a bunch of multiple > takes on things. > > The one I was personally expecting at the start of the thread was the > thing that was dicussed once before [1] -- something like Johnny Lee's > Wiimote hack [2], but without the Wiimote hack. For such an > application, it's not obvious to me that there's a need for detection > of, say, pitch, yaw, or roll, other than maybe being robust to their > presence. (For example, if you roll your head, both the in-world > camera and your real-world head are already rotating -- so why should > the orientation of the world change with respect to the orientation of > the screen? It's not like the screen is moving along with your > head.) Something pretty basic would probably be okay. > > Another take seems to be like treating movements like generic gestures > and mapping them to commands or controls with less constraint. > Something like TrackIR seems to try to exaggerate all the motions, > even stuff like roll. > > Yet another take includes mouth and eye movements, etc. like that > Logitech demo. I agree that this would be very nice, but this seems > like it'd need server-side support too to be useful, and maybe it's > outside the scope of what was intended.... > > I think we need to settle on our expectations before figuring out > which libraries are best. > > [1] > https://lists.secondlife.com/pipermail/sldev/2008-September/011863.html > [2] http://www.youtube.com/watch?v=Jd3-eiid-Uw > > Celi > > On Thu, May 21, 2009 at 9:56 PM, Stickman > wrote: > > This is a huge thread for a feature I wouldn't use.... > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Thu May 21 21:34:43 2009 From: melinda at superliminal.com (Melinda Green) Date: Thu, 21 May 2009 21:34:43 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A161C37.20002@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> <4A161C37.20002@gmail.com> Message-ID: <4A162B63.7010503@superliminal.com> Jan Ciger wrote: > [...] > It would then be trivial to interface basically anything to SL, if the > viewer would take camera matrix and allow avatar control from outside. > And Lindens wouldn't have to maintain the device specific stuff neither. I think some people are misunderstanding what is being asked for here. I could be wrong myself but my understanding is that Philip and Merov's intent is to simply translate user head movements into avatar gestures. Even something as simple as recognizing when the user appears to be nodding "yes" or shaking their head "no" and then triggering the appropriate gestures would be extremely cool and worth implementing. I didn't interpret anything in what was asked to suggest controlling the camera, tracking gazes, or anything else. It certainly looks as if all sorts of interesting ideas are being generated and should definitely be captured. I certainly don't want to stop the brainstorming, but I think it would be helpful to first see how we could most easily trigger head gestures from video input before we attempt to design the best, most powerful API and implementations for full VR/MC support in SL. -Melinda From dzonatas at gmail.com Thu May 21 21:58:16 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 21 May 2009 21:58:16 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> Message-ID: <4A1630E8.7010600@gmail.com> Celierra Darling wrote: > Yet another take includes mouth and eye movements, etc. like that > Logitech demo.? I agree that this would be very nice, but this seems > like it'd need server-side support too to be useful, and maybe it's > outside the scope of what was intended.... As long as the maximum number of combined animations that play at once is not reached, there would not be a need to immediately change the server side. Some of this basic implementation could be started with LSL just to get the right generic animations. The next version could easily be done on the viewer side to play multiple gestures made up of the generic animations mentioned above. Chat: /headtiltleft /blink /smile Next step would be to hook up a the device driver and have it send one of these chat messages to the viewer. Once everything works correctly, then we can optimize it for more advanced uses with better interfaces. Need to start simple and generic, but not to simple. I'm already writing code that *can* easily make this happen now, if anybody is interested: http://wiki.secondlife.com/wiki/Alternate_viewers#MonoVida_Studio From moriz.gupte at gmail.com Thu May 21 22:40:11 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Thu, 21 May 2009 23:40:11 -0600 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A162B63.7010503@superliminal.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> <4A161C37.20002@gmail.com> <4A162B63.7010503@superliminal.com> Message-ID: I think that with the exception of 'yes' and 'no', the thought of translating head motions to 'construct' a facial expression or a gesture expression or even implement FACS (I dont think Philip meant that) seems at least to me to much more complex -- probably why I interpreted Philip's post the way I did. And I do not recommend using the very narrow channel of information that head motions provide to drive a wide range of avatar gestures...because this channel will be so noisy, that a lot of ambiguities will arise, so much that it will cease to become useful. So what looks the 'simple' low bearing fruit... might ultimately be problematic. On Thu, May 21, 2009 at 10:34 PM, Melinda Green wrote: > my understanding is that Philip and Merov's > intent is to simply translate user head movements into avatar gestures. > -- Rameshsharma Ramloll PhD Research Assistant Professor Idaho State University, PocatelloTel: 208-282-5333 More info at http://tr.im/RRamloll -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090521/09b0a4f5/attachment.htm From dzonatas at gmail.com Thu May 21 23:21:52 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 21 May 2009 23:21:52 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> <4A161C37.20002@gmail.com> <4A162B63.7010503@superliminal.com> Message-ID: <4A164480.4020802@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090521/da0d4cf1/attachment.htm From tigrospottystripes at gmail.com Thu May 21 23:08:14 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 22 May 2009 03:08:14 -0300 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A164480.4020802@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> <4A161C37.20002@gmail.com> <4A162B63.7010503@superliminal.com> <4A164480.4020802@gmail.com> Message-ID: <4A16414E.3000905@Gmail.com> how about doing it like how it's done for voice levels in voice gestures? Dzonatas Sol escreveu: > Not everybody will wear a human face in VR, so there is merit to use > avatar gestures. A specific interface would require a one to one > relationship between the human face and the avatar face. There may be > different gestures needed when the human face performs certain > actions. To keep it in avatar gestures lets us not rely on that > one-to-one relationship. A middle layer between the human facial > gestures can act to translate the current shape of the avatar face. > The avatar may have several heads (I've seen 7 headed dragons) and > maybe someone wants to control them all with human facial gestures. > Something that is too specific in a one-to-one relationship wouldn't > allow that to happen. > > I think a channel that sends recognized avatar gestures would be less > noisy than a channel that sends all head motions and facial positions, > continuously. > > Moriz Gupte wrote: >> I think that with the exception of 'yes' and 'no', the thought of >> translating head motions to 'construct' a facial expression or a >> gesture expression or even implement FACS >> (I dont >> think Philip meant that) >> seems at least to me to much more complex -- probably why I >> interpreted Philip's post the way I did. >> And I do not recommend using the very narrow channel of information >> that head motions provide to drive a wide range of avatar >> gestures...because this channel will be so noisy, that a lot of >> ambiguities will arise, so much that it will cease to become useful. >> So what looks the 'simple' low bearing fruit... might ultimately be >> problematic. >> >> On Thu, May 21, 2009 at 10:34 PM, Melinda Green >> > wrote: >> >> my understanding is that Philip and Merov's >> intent is to simply translate user head movements into avatar >> gestures. >> >> >> >> >> -- >> Rameshsharma Ramloll PhD Research Assistant Professor Idaho State >> University, PocatelloTel: 208-282-5333 >> More info at http://tr.im/RRamloll >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 Thu May 21 23:26:56 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 22 May 2009 03:26:56 -0300 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A164480.4020802@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> <4A161C37.20002@gmail.com> <4A162B63.7010503@superliminal.com> <4A164480.4020802@gmail.com> Message-ID: <4A1645B0.60307@Gmail.com> actually, how about a mini "programing language" for the gestures (here used in the regular SL sense) triggers to allow flexibility in expression detection, with one or two characters identifying which face part followed by a number specifying a range of position, perhaps two digits to make the range thing more flexible like, for the "wtf?! o.0 " gesture the trigger could be somthing like LE79RE13 (which translates to Left Eye between quite open and absurdly open, and Right Eye from almost closed to slightly closed) we could have specific markers for the corners of the mouth, the upper lip, the bottom lip, the chin, left and right cheeks/cheekbones, the eyebrows and I'm not sure there is more to track (other than gaze direction), ah, of course, tonuge! :P since the tongue can move out but also sideways, there coudl be two different marks, TO for tongue and TS for Toungue Sideways, or if 10 is too little resolution for tongue movement make one for each side, and if going to one side the marker for the other is zero, hm, actually, we will need one for TV Tongue Vertical, for vertical movements of the tongue as well (and for the resolution issue if present, just to TU and TD like for sideways movement) Dzonatas Sol escreveu: > Not everybody will wear a human face in VR, so there is merit to use > avatar gestures. A specific interface would require a one to one > relationship between the human face and the avatar face. There may be > different gestures needed when the human face performs certain > actions. To keep it in avatar gestures lets us not rely on that > one-to-one relationship. A middle layer between the human facial > gestures can act to translate the current shape of the avatar face. > The avatar may have several heads (I've seen 7 headed dragons) and > maybe someone wants to control them all with human facial gestures. > Something that is too specific in a one-to-one relationship wouldn't > allow that to happen. > > I think a channel that sends recognized avatar gestures would be less > noisy than a channel that sends all head motions and facial positions, > continuously. > > Moriz Gupte wrote: >> I think that with the exception of 'yes' and 'no', the thought of >> translating head motions to 'construct' a facial expression or a >> gesture expression or even implement FACS >> (I dont >> think Philip meant that) >> seems at least to me to much more complex -- probably why I >> interpreted Philip's post the way I did. >> And I do not recommend using the very narrow channel of information >> that head motions provide to drive a wide range of avatar >> gestures...because this channel will be so noisy, that a lot of >> ambiguities will arise, so much that it will cease to become useful. >> So what looks the 'simple' low bearing fruit... might ultimately be >> problematic. >> >> On Thu, May 21, 2009 at 10:34 PM, Melinda Green >> > wrote: >> >> my understanding is that Philip and Merov's >> intent is to simply translate user head movements into avatar >> gestures. >> >> >> >> >> -- >> Rameshsharma Ramloll PhD Research Assistant Professor Idaho State >> University, PocatelloTel: 208-282-5333 >> More info at http://tr.im/RRamloll >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 May 21 23:40:43 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 21 May 2009 23:40:43 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A1645B0.60307@Gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> <4A161C37.20002@gmail.com> <4A162B63.7010503@superliminal.com> <4A164480.4020802@gmail.com> <4A1645B0.60307@Gmail.com> Message-ID: along those lines, better access to the avatar facial morphs (besides the provided animations) would be nice to have :) On Thu, May 21, 2009 at 11:26 PM, Tigro Spottystripes < tigrospottystripes at gmail.com> wrote: > actually, how about a mini "programing language" for the gestures (here > used in the regular SL sense) triggers to allow flexibility in > expression detection, with one or two characters identifying which face > part followed by a number specifying a range of position, perhaps two > digits to make the range thing more flexible > > like, for the "wtf?! o.0 " gesture the trigger could be somthing like > LE79RE13 (which translates to Left Eye between quite open and absurdly > open, and Right Eye from almost closed to slightly closed) > > we could have specific markers for the corners of the mouth, the upper > lip, the bottom lip, the chin, left and right cheeks/cheekbones, the > eyebrows and I'm not sure there is more to track (other than gaze > direction), ah, of course, tonuge! :P > > since the tongue can move out but also sideways, there coudl be two > different marks, TO for tongue and TS for Toungue Sideways, or if 10 is > too little resolution for tongue movement make one for each side, and if > going to one side the marker for the other is zero, hm, actually, we > will need one for TV Tongue Vertical, for vertical movements of the > tongue as well (and for the resolution issue if present, just to TU and > TD like for sideways movement) > > Dzonatas Sol escreveu: > > Not everybody will wear a human face in VR, so there is merit to use > > avatar gestures. A specific interface would require a one to one > > relationship between the human face and the avatar face. There may be > > different gestures needed when the human face performs certain > > actions. To keep it in avatar gestures lets us not rely on that > > one-to-one relationship. A middle layer between the human facial > > gestures can act to translate the current shape of the avatar face. > > The avatar may have several heads (I've seen 7 headed dragons) and > > maybe someone wants to control them all with human facial gestures. > > Something that is too specific in a one-to-one relationship wouldn't > > allow that to happen. > > > > I think a channel that sends recognized avatar gestures would be less > > noisy than a channel that sends all head motions and facial positions, > > continuously. > > > > Moriz Gupte wrote: > >> I think that with the exception of 'yes' and 'no', the thought of > >> translating head motions to 'construct' a facial expression or a > >> gesture expression or even implement FACS > >> (I dont > >> think Philip meant that) > >> seems at least to me to much more complex -- probably why I > >> interpreted Philip's post the way I did. > >> And I do not recommend using the very narrow channel of information > >> that head motions provide to drive a wide range of avatar > >> gestures...because this channel will be so noisy, that a lot of > >> ambiguities will arise, so much that it will cease to become useful. > >> So what looks the 'simple' low bearing fruit... might ultimately be > >> problematic. > >> > >> On Thu, May 21, 2009 at 10:34 PM, Melinda Green > >> > wrote: > >> > >> my understanding is that Philip and Merov's > >> intent is to simply translate user head movements into avatar > >> gestures. > >> > >> > >> > >> > >> -- > >> Rameshsharma Ramloll PhD Research Assistant Professor Idaho State > >> University, PocatelloTel: 208-282-5333 > >> More info at http://tr.im/RRamloll > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> 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/20090521/459b4ea5/attachment-0001.htm From melinda at superliminal.com Fri May 22 00:18:15 2009 From: melinda at superliminal.com (Melinda Green) Date: Fri, 22 May 2009 00:18:15 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A1645B0.60307@Gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> <4A161C37.20002@gmail.com> <4A162B63.7010503@superliminal.com> <4A164480.4020802@gmail.com> <4A1645B0.60307@Gmail.com> Message-ID: <4A1651B7.9030206@superliminal.com> I'm glad that we're narrowing the scope of the discussion toward what can be done in the short term. I think that triggering existing animations is definitely the low-hanging fruit because it won't require any server changes. I interpret the challenge to be figuring out what can be done quickly and easily. I think that facial gestures are probably within the realm of the immediately possible though I still like the idea of trying to ground the discussion by focusing on what would be required to recognize yes/no head motion triggers and turn them into avatar head animations. Just achieving that one proof-of-concept will tell us a *lot* about what else we could or should be attempting to do with this. Regarding facial animations, the one idea that Tigro gives me which almost seems to cute *not* to consider is making sure that his facial character codes use standard text emoticons instead of numbers. How cute would it be if a tongue-to-the-right was encoded with colon+P and tongue-to-the-right was colon+b? It might be impossible to encode the whole range of simple faces using unicode emoticons, but one nice benefit would be that we could also parse them out of text chat and trigger the faces that users already naturally type as a poor-man's way of expressing emotion. But again, that's just a cute bit of fun. The important thing is the first part about simply detecting and triggering head shakes and nods from video input without any tracking dots or other special user set-up. What's the easiest way to do that? -Melinda Tigro Spottystripes wrote: > actually, how about a mini "programing language" for the gestures (here > used in the regular SL sense) triggers to allow flexibility in > expression detection, with one or two characters identifying which face > part followed by a number specifying a range of position, perhaps two > digits to make the range thing more flexible > > like, for the "wtf?! o.0 " gesture the trigger could be somthing like > LE79RE13 (which translates to Left Eye between quite open and absurdly > open, and Right Eye from almost closed to slightly closed) > > we could have specific markers for the corners of the mouth, the upper > lip, the bottom lip, the chin, left and right cheeks/cheekbones, the > eyebrows and I'm not sure there is more to track (other than gaze > direction), ah, of course, tonuge! :P > > since the tongue can move out but also sideways, there coudl be two > different marks, TO for tongue and TS for Toungue Sideways, or if 10 is > too little resolution for tongue movement make one for each side, and if > going to one side the marker for the other is zero, hm, actually, we > will need one for TV Tongue Vertical, for vertical movements of the > tongue as well (and for the resolution issue if present, just to TU and > TD like for sideways movement) > > Dzonatas Sol escreveu: > >> Not everybody will wear a human face in VR, so there is merit to use >> avatar gestures. A specific interface would require a one to one >> relationship between the human face and the avatar face. There may be >> different gestures needed when the human face performs certain >> actions. To keep it in avatar gestures lets us not rely on that >> one-to-one relationship. A middle layer between the human facial >> gestures can act to translate the current shape of the avatar face. >> The avatar may have several heads (I've seen 7 headed dragons) and >> maybe someone wants to control them all with human facial gestures. >> Something that is too specific in a one-to-one relationship wouldn't >> allow that to happen. >> >> I think a channel that sends recognized avatar gestures would be less >> noisy than a channel that sends all head motions and facial positions, >> continuously. >> >> Moriz Gupte wrote: >> >>> I think that with the exception of 'yes' and 'no', the thought of >>> translating head motions to 'construct' a facial expression or a >>> gesture expression or even implement FACS >>> (I dont >>> think Philip meant that) >>> seems at least to me to much more complex -- probably why I >>> interpreted Philip's post the way I did. >>> And I do not recommend using the very narrow channel of information >>> that head motions provide to drive a wide range of avatar >>> gestures...because this channel will be so noisy, that a lot of >>> ambiguities will arise, so much that it will cease to become useful. >>> So what looks the 'simple' low bearing fruit... might ultimately be >>> problematic. >>> >>> On Thu, May 21, 2009 at 10:34 PM, Melinda Green >>> > wrote: >>> >>> my understanding is that Philip and Merov's >>> intent is to simply translate user head movements into avatar >>> gestures. >>> >>> >>> >>> >>> -- >>> Rameshsharma Ramloll PhD Research Assistant Professor Idaho State >>> University, PocatelloTel: 208-282-5333 >>> More info at http://tr.im/RRamloll >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 aimee.trescothick at gmail.com Fri May 22 05:32:03 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Fri, 22 May 2009 13:32:03 +0100 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A162B63.7010503@superliminal.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> <4A161C37.20002@gmail.com> <4A162B63.7010503@superliminal.com> Message-ID: <479F8CAE-240E-4C00-89B9-C75EE6E16706@gmail.com> On 22 May 2009, at 05:34, Melinda Green wrote: > I think some people are misunderstanding what is being asked for > here. I > could be wrong myself but my understanding is that Philip and Merov's > intent is to simply translate user head movements into avatar > gestures. Sooo, basically what you're actually after is something like this ... ? http://www.youtube.com/watch?v=h27CEpque34 http://sl.vr-wear.com/ Aimee. From moriz.gupte at gmail.com Fri May 22 06:48:56 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Fri, 22 May 2009 07:48:56 -0600 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A16414E.3000905@Gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> <4A161C37.20002@gmail.com> <4A162B63.7010503@superliminal.com> <4A164480.4020802@gmail.com> <4A16414E.3000905@Gmail.com> Message-ID: *I understand that this thread is becoming long, please forgive me, but this is so interesting and bound to lead to some really interesting results* Right on Tigro, you raise a very important point. by noisy I did not mean... noise in the signal..but cognitive noise (when a piece of info ceases to have its intended meaning)...when one channel of communication is so over utilized (in an un-natural way) that it is no longer functional because the 'actor' cease to feel in full control of the expressive medium. This is exactly what happens with voice controlled avatar gesturing... I shut it off...because the resulting 'Parkinson' effect (when avatar moves about meaninglessly..) has become noise and is a distraction. In human communication, we often have multiple synchronous and redundant channels which serves to resolve expressive ambiguities in real time. For e.g. there are many more ambiguities to resolve if you have access only to a sign language... or are blind and need to use voice to express urself than if both channels are used... On Fri, May 22, 2009 at 12:08 AM, Tigro Spottystripes < tigrospottystripes at gmail.com> wrote: > how about doing it like how it's done for voice levels in voice gestures? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090522/3110d6f0/attachment.htm From nivardus at gmail.com Fri May 22 08:15:20 2009 From: nivardus at gmail.com (nivardus at gmail.com) Date: Fri, 22 May 2009 15:15:20 +0000 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15AEBC.7070800@lindenlab.com> Message-ID: <0021cc022382965298046a81baad@google.com> This discussion reminds me of the idea to provide an API for LL's puppetiering project so people could write different plug-in applications to power avatar movement, rather than using lackluster mouse-control. An example implementation would be camera recognition of hand position: even if the user had to wear colored tape on his or her fingers the direct control of an avatar's limbs would be rather liberating (3D movement calculated by scale of hand and x, y, position, or with a depth-sensitive camera.) Head position and point tracking are two relatively well-established techniques; while they still can --like most image recognition technology-- be finicky, both potentially could provide pathways to a more expressive Second Life. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090522/cf770bd9/attachment.htm From jan.ciger at gmail.com Fri May 22 08:20:12 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 22 May 2009 17:20:12 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A162167.1080207@Gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15B7EA.70907@lindenlab.com> <4A15BB29.1020401@Gmail.com> <4A15BDE5.8030805@gmail.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> <4A1616A7.4090002@gmail.com> <4A162167.1080207@Gmail.com> Message-ID: <4A16C2AC.3030603@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tigro Spottystripes wrote: > according to Wikipedia: > "At NaturalPoint's request, FreeTrack project members removed the > strings from the software they provide to end users. FreeTrack then > implemented a workaround which creates a local copy of these strings > from the client software when used with TrackIR Enhanced titles. > FreeTrack project members argue that copyright is not violated in this > case since it may fall under the provision of 17 U.S.C. ? 117 " > > Though it then follows mentioning that more recent versions of the > TrackIR software uses encryption to communicate with games and such to > try to kick Freetrack out of the way again, but there are workarounds to > make some of the new programs be compatible with Freetrack again. Well, sorry. This kind of stuff is unusable for any serious project. Regardless of whether or not they are in the clear legally, what if the court orders them to remove and cease to distribute the code? Then you and your project are left facing an expensive rewrite. As a project manager I would avoid something like this by a wide margin. A chilling effect, that is for sure, but I do not have money to get into a legal fight. > I have no experience with TrackIR's own programs, but you mentioned that > you can't look left without having the monitor be out of your field of > view, Freetrack can map all the axis, so you can look left without > having to use mirrors to see the monitor, you can actually look 180 > degrees or more without ever moving anything bellow the neck and still > keep the monitor in plain sight easily, hell, you can look to the bottom > of the screen and have the view go past showing your avatar feet and > seeing what is behind you upside down :P You have missed my point. Of course, you can remap anything, that is not the problem. You can also map 1 degree head movement to 45 degree camera movement or increase the camera field of view. However, what good is that? Your neck muscles will be strained like hell, because you will have difficulty to keep the camera still. Do you want the user to have fun or to get a muscle cramp? Furthermore, you can control the camera with a lot better precision using a mouse already - so your gadget is at best a complicated toy to show off, but with little practical benefit over a simpler device if you are constrained to the screen and desk anyway. If you had a stand-up setup (e.g. a large projection screen or cave) where a mouse is unusable, then this would make a lot more sense. This holds whether you use Natural Point TrackIR or Freetrack or something else in this way - it is just wrong interface paradigm for the job. People often forget that virtual reality is not only about the technology but also usability. They build crazy contraptions just because it is possible to build them. Developers get target fixation and do not realize that the stuff they have designed is ultimately an useless gimmick. When teaching VR to my students, I am always telling them - "What makes you to *require* this interface? Why is it better than the usual xyz? What does it improve?" Usually they cannot answer these questions - precisely because they built the thing because it is "cool" and not because it is actually useful. Sometimes I let them build their contraption and try it out - and they tend to conclude themselves that it wasn't the best idea :) I am working in the VR field since about 1998 and I have seen a lot of expensive, outright crazy and unusable devices that work actually worse than the usual keyboard and mouse. This trend, together with the unbelievable hype by companies trying to market their gadgets and clueless journalists, has a lot to do with the bad reputation that the field has got, even though there are many genuinely useful applications. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFsKpn11XseNj94gRAuxxAJ0QynrGhfJxdPDGbA6Ccp7vzm0NgwCeJrqh a4sWvSZBB/INa34mmOwIzVM= =9Fqi -----END PGP SIGNATURE----- From jan.ciger at gmail.com Fri May 22 08:24:57 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 22 May 2009 17:24:57 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A162B63.7010503@superliminal.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15DC42.6060802@gmail.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> <4A161C37.20002@gmail.com> <4A162B63.7010503@superliminal.com> Message-ID: <4A16C3C9.5080900@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Melinda, Melinda Green wrote: > I think some people are misunderstanding what is being asked for here. I > could be wrong myself but my understanding is that Philip and Merov's > intent is to simply translate user head movements into avatar gestures. > Even something as simple as recognizing when the user appears to be > nodding "yes" or shaking their head "no" and then triggering the > appropriate gestures would be extremely cool and worth implementing. That is not what I have understood and the Logitech video was not showing that neither. But you may be right - it would be good to get things clarified from Lindens. > I > didn't interpret anything in what was asked to suggest controlling the > camera, tracking gazes, or anything else. The camera control was in the original mail: Philip: > Is OpenCV the best package for extracting basic head > position/gesture information from a camera image stream? And his second mail: > This is what we want - simple head position and movement tracking from a camera. I agree with the gaze tracking and the rest - that is a different kettle of fish that was asked about by other people. > It certainly looks as if all > sorts of interesting ideas are being generated and should definitely be > captured. I certainly don't want to stop the brainstorming, but I think > it would be helpful to first see how we could most easily trigger head > gestures from video input before we attempt to design the best, most > powerful API and implementations for full VR/MC support in SL. I think that there is a confusion about the "gesture" term. Gestures can mean SL gestures (essentially an animation + chat) and also movement over time performed by human that needs to be captured and recognized - an incredibly difficult job, much more difficult and complex than e.g. tracking a position of the head. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFsPJn11XseNj94gRAgDNAKDC2U18HTrCRjl0SRlpATECJaGhFACfVlBi dU1Af8B0kjFWYb4gNs93RKQ= =GJLR -----END PGP SIGNATURE----- From jan.ciger at gmail.com Fri May 22 08:31:26 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 22 May 2009 17:31:26 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A1651B7.9030206@superliminal.com> References: <4A15AEBC.7070800@lindenlab.com> <4A15F1DB.2080705@gmail.com> <4A16132B.2050009@gmail.com> <4A1613D7.6020203@Gmail.com> <4A161C37.20002@gmail.com> <4A162B63.7010503@superliminal.com> <4A164480.4020802@gmail.com> <4A1645B0.60307@Gmail.com> <4A1651B7.9030206@superliminal.com> Message-ID: <4A16C54E.2060604@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Melinda Green wrote: > I'm glad that we're narrowing the scope of the discussion toward what > can be done in the short term. I think that triggering existing > animations is definitely the low-hanging fruit because it won't > require any server changes. Folks, this is not what Lindens asked about. I think you have got on a (interesting) tangent. This is what Philip was asking for: > Is OpenCV the best package for extracting basic head > position/gesture information from a camera image stream? (Gestures in this sense are user's head movement, not SL gestures! E.g. nodding your head could be interpreted as a mouse click!) And: > This is what we want - simple head position and movement tracking from a camera. So all this SL gesture triggering and extraction discussion is a bit off-topic, IMO. The low hanging fruit is really to get basic tracking in place, because that is the input required for any gesture triggering or camera control or whatever. Whether or not this requires server changes is completely immaterial - there are much larger problems there (e.g. how to capture video in a cross-platform way, supporting all kinds of webcams!). Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFsVOn11XseNj94gRAhhNAJ9cbqg25jydJ/CCwSRbw6zjtsLtPgCcD4DA oyV2SFJGVTbP9yvaLgayCU4= =xD4H -----END PGP SIGNATURE----- From jan.ciger at gmail.com Fri May 22 08:36:32 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 22 May 2009 17:36:32 +0200 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A161CD0.7020600@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> <4A161CD0.7020600@lindenlab.com> Message-ID: <4A16C680.9020607@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Lanphier wrote: > On 05/21/2009 12:42 PM, Philip Rosedale wrote: >> Has anyone here worked with camera-based gesture recognition before? >> How about OpenCV? Is OpenCV the best package for extracting basic head >> position/gesture information from a camera image stream? Merov and I >> are pondering a Snowglobe project to detect head motion from simple >> cameras and connect it to the SL Viewer > > This thread has certainly generated a lot of interest. Any volunteers to > summarize the information from this thread on the wiki? > > https://wiki.secondlife.com/wiki/Camera-based_gesture_recognition > > Rob > I could probably contribute a little test program using CamShift to track the face position/tilt and feed that information out using e.g. VRPN. That is fairly easy to do. I would connect it to the viewer, but I am not that familiar with the camera code. Probably the simplest hack would be to attach it to the Flycam code for the testing (instead of using pitch/yaw/roll from a joystick, get a VRPN quaternion). If you are interested in that, contact me off-list. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFsaAn11XseNj94gRAvMSAKDKiJ38Ldk9bQQy+8SxnJ/ypqsBCgCgsoLj 0uRGRjlcOmELdUw06LB67Eo= =Y5Wx -----END PGP SIGNATURE----- From philip at lindenlab.com Fri May 22 10:50:52 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Fri, 22 May 2009 10:50:52 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A16C680.9020607@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A161CD0.7020600@lindenlab.com> <4A16C680.9020607@gmail.com> Message-ID: <4A16E5FC.6050403@lindenlab.com> Good conversation, overall confirms the direction we've been thinking. OK, so I put up a new page in the wiki which is a project page for the specific work we're thinking of doing next: https://wiki.secondlife.com/wiki/Gesture_Recognition We have an intern starting at beginning of June who will work on this project. It would be fabulous if someone here wants to do a patch for Snowglobe that does the viewer side of this (see doc), which is to listen for local network packets and trigger gestures and set lookAt based on the contents of those packets. That would allow us to have the intern focus totally on the recognition/analysis app, and would also allow folks in the community who want to play with other hardware or analysis algorithms to do so. Summary: hopefully this summer we can update Snowglobe to make your avatar nod, shake its head, and look around in response to what a commodity webcam can see. Philip From melinda at superliminal.com Fri May 22 12:44:49 2009 From: melinda at superliminal.com (Melinda Green) Date: Fri, 22 May 2009 12:44:49 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A16E5FC.6050403@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> <4A161CD0.7020600@lindenlab.com> <4A16C680.9020607@gmail.com> <4A16E5FC.6050403@lindenlab.com> Message-ID: <4A1700B1.50600@superliminal.com> Philip Rosedale wrote: > Good conversation, overall confirms the direction we've been thinking. > OK, so I put up a new page in the wiki which is a project page for the > specific work we're thinking of doing next: > > https://wiki.secondlife.com/wiki/Gesture_Recognition > > We have an intern starting at beginning of June who will work on this > project. It would be fabulous if someone here wants to do a patch for > Snowglobe that does the viewer side of this (see doc), which is to > listen for local network packets and trigger gestures and set lookAt > based on the contents of those packets. That would allow us to have the > intern focus totally on the recognition/analysis app, and would also > allow folks in the community who want to play with other hardware or > analysis algorithms to do so. > > Summary: hopefully this summer we can update Snowglobe to make your > avatar nod, shake its head, and look around in response to what a > commodity webcam can see. OK, this is very helpful information. It clears up the confusion around whether you were looking to trigger high-level gestures (or other action) versus translating user motion into avatar movements. It turns out that you want to do both. :-) That raises some interesting questions about how these two input streams will interact with each other, but the viewer already contains a rich avatar animation layering mechanism so it should be straightforward to find a good priority for the animation part. The look-at system has a similar priority system and a suitable priority will need to be chosen for this part as well. And of course we'll need two new saved settings so that a user can enable/disable each part independently. In order to get my head around the project I created the attached diagram showing the design space in which we're working. I think it will be important in these discussions to always be clear which data paths we're talking about at any particular time. -Melinda -------------- next part -------------- A non-text attachment was scrubbed... Name: gestures.png Type: image/png Size: 6230 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090522/31be215a/attachment.png From dzonatas at gmail.com Fri May 22 13:39:39 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 22 May 2009 13:39:39 -0700 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A16E5FC.6050403@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> <4A161CD0.7020600@lindenlab.com> <4A16C680.9020607@gmail.com> <4A16E5FC.6050403@lindenlab.com> Message-ID: <4A170D8B.1050404@gmail.com> Without much eyeballs on the code yet, it appears newview/llvoiceclient.h/cpp can be pretty much shallow copied and used to get a head start on this. * Personally, I would do this copy and replace the vivox specific IO with the standard XML interpreter (if not already done). * Even if llgestureclient.h/cpp seems like the logical new name for it, I think I would start off with llgenericxmlclient.h/cpp and derive from there. Some viewers already have a socket interface to local apps, maybe they already have done above to some degree and can easily change it to meet such criteria of XML. In my viewer, I have the option to either support an API (to libsnowglobe.so) that handles the dynamics of UTF16 or UTF8 across platforms, which would mean duplicate methods for both cases, platform specific selection messes, and more just to access the LL-API. It would be easier if I just used the XML client interface, which would let the XML interpreter do the job to detect and translate between the wide variety of different UTF formats and not worry about word size or endianess. I may have something to submit. =) Philip Rosedale wrote: > It would be fabulous if someone here wants to do a patch for > Snowglobe that does the viewer side of this (see doc), which is to > listen for local network packets and trigger gestures and set lookAt > based on the contents of those packets. From rweave at gmail.com Fri May 22 13:29:49 2009 From: rweave at gmail.com (rweave at gmail.com) Date: Fri, 22 May 2009 15:29:49 -0500 Subject: [sldev] Avatar Animation Message-ID: <2009522152949.841446@PC> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090522/13bdf454/attachment.htm From melinda at superliminal.com Fri May 22 13:48:35 2009 From: melinda at superliminal.com (Melinda Green) Date: Fri, 22 May 2009 13:48:35 -0700 Subject: [sldev] Avatar Animation In-Reply-To: <2009522152949.841446@PC> References: <2009522152949.841446@PC> Message-ID: <4A170FA3.2010601@superliminal.com> Second Life already supports all of these things but they're not terribly well tuned. Someone already mentioned that it supports voice-triggered gestures as well as lip sync but the quality is questionable. It also supports a rich avatar attention system that I did a lot of work on to allow it to be tuned/customized. It's currently difficult to notice, but when your head joint is not overridden by something of higher priority, your head will simetimes turn to look at nearby people when they type. Your head will also lock onto anything or anyone that you alt-click on, but that's hard to see because it also moves your camera, but they will see you turning to look at those things and people. The work I did can also let you choose what/who you look at whenever you left click on them. That's a great way to explicitly give attention to other people. Notice also that when you look at an object, you'll look at it's center, but when you look at a person, you'll look directly into their eyes. If you want to play with this system, the easiest way is to start by replacing the attentions.xml file in the character directory with the example attentionsN.xml. Examine their differences and you'll start to see the power of what can be done by simply tuning the parameters. -Melinda rweave at gmail.com wrote: > This is my first post and I hope I am not far off topic here. If I > am, I ask your tolerance. > > I have been following this thread concerning user tracking to animate > the Avatar. I would like to point out an interesting approach used > by There.com. There.com uses speech recognition to extract cues to > animate the avatars. As one is speaking, the avatar makes very > lifelike movements. Lip sync is excellent and facial expressions as > well as posture and hand gestures quite realistically follow the > content of the speech. While this may not be as sophisticated as head > tracking, it does lend a great deal of realism to the experience there. > > It would seem to me that this method of avatar animation would be > easier to implement than tracking the users head movements and facial > expressions and then translating these data to avatar movements. > > As a slight aside, avatars in There.com frequently make eye contact. > This is sadly missing and depersonalizing in Second Life. > > I enjoy this mailing list a great deal and I know I am among esteemed > company here. > > eRobert Allen > ------------------------------------------------------------------------ > > _______________________________________________ > 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 philip at lindenlab.com Fri May 22 14:09:43 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Fri, 22 May 2009 14:09:43 -0700 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A170D8B.1050404@gmail.com> References: <4A15AEBC.7070800@lindenlab.com> <4A161CD0.7020600@lindenlab.com> <4A16C680.9020607@gmail.com> <4A16E5FC.6050403@lindenlab.com> <4A170D8B.1050404@gmail.com> Message-ID: <4A171497.2000302@lindenlab.com> do we need to use any sort of XML intepreter? My preference would be simple UDP with the contents being a name/value pair: gesture/nod lookatPoint/100,100,100 etc. Seems important that this be extremely lightweight and fast. I'm a bit out of the loop, development wise, so maybe i'm wrong. P Dzonatas Sol wrote: > Without much eyeballs on the code yet, it appears > newview/llvoiceclient.h/cpp can be pretty much shallow copied and used > to get a head start on this. > > * Personally, I would do this copy and replace the vivox specific IO > with the standard XML interpreter (if not already done). > * Even if llgestureclient.h/cpp seems like the logical new name for it, > I think I would start off with llgenericxmlclient.h/cpp and derive from > there. > > Some viewers already have a socket interface to local apps, maybe they > already have done above to some degree and can easily change it to meet > such criteria of XML. > > In my viewer, I have the option to either support an API (to > libsnowglobe.so) that handles the dynamics of UTF16 or UTF8 across > platforms, which would mean duplicate methods for both cases, platform > specific selection messes, and more just to access the LL-API. It would > be easier if I just used the XML client interface, which would let the > XML interpreter do the job to detect and translate between the wide > variety of different UTF formats and not worry about word size or endianess. > > I may have something to submit. =) > > Philip Rosedale wrote: > >> It would be fabulous if someone here wants to do a patch for >> Snowglobe that does the viewer side of this (see doc), which is to >> listen for local network packets and trigger gestures and set lookAt >> based on the contents of those packets. >> > > _______________________________________________ > 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/20090522/4fd8c40f/attachment-0001.htm From jan.ciger at gmail.com Fri May 22 14:29:43 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 22 May 2009 23:29:43 +0200 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A171497.2000302@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> Message-ID: <4A171947.9050709@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philip Rosedale wrote: > do we need to use any sort of XML intepreter? My preference would > be simple UDP with the contents being a name/value pair: > > gesture/nod lookatPoint/100,100,100 > > etc. Seems important that this be extremely lightweight and fast. > I'm a bit out of the loop, development wise, so maybe i'm wrong. > XML is definitely an overkill and certainly shouldn't be used for anything that has aspirations to be lightweight. Just use DBus - that is pretty standard and portable lightweight RPC mechanism and it is in the viewer already - it is used for passing slurls to the viewer from Linux browser. That would also allow easy scripting of the viewer in the future. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFxlEn11XseNj94gRAgk+AKCf6NMe7eucWoOuw9KBIB/591lI+ACff7sZ riJo1IBoVWvcil/3tQ+d1jU= =17TQ -----END PGP SIGNATURE----- From robla at lindenlab.com Fri May 22 14:36:13 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 22 May 2009 14:36:13 -0700 Subject: [sldev] snowglobe-automails mailing list Message-ID: <4A171ACD.50402@lindenlab.com> Hi all, We've already got a few standard robot-generated emails, and with the discussion about automails about crash stats (http://jira.secondlife.com/browse/VWR-13573 ), we sort of hit the tipping point with needing a place for people who are just interested in Snowglobe related stuff to subscribe to. So, I've created a new mailing list ("snowglobe-automails@") which will eventually aggregate all of this stuff: https://lists.secondlife.com/cgi-bin/mailman/listinfo/snowglobe-automails There's still some wiring up to do to get all of the stuff we want headed to this list, so for now, it's going to be low traffic. Over time, there's going to be more and more information headed to this list. Comments should be directed here: http://jira.secondlife.com/browse/VWR-13573 Rob From dzonatas at gmail.com Fri May 22 14:56:32 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 22 May 2009 14:56:32 -0700 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A171497.2000302@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> Message-ID: <4A171F90.1000007@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090522/3268ad53/attachment.htm From dzonatas at gmail.com Fri May 22 15:39:43 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 22 May 2009 15:39:43 -0700 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A171947.9050709@gmail.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> Message-ID: <4A1729AF.5070100@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090522/50ea02c4/attachment.htm From jan.ciger at gmail.com Fri May 22 15:30:00 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sat, 23 May 2009 00:30:00 +0200 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A171F90.1000007@gmail.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> <4A171F90.1000007@gmail.com> Message-ID: <4A172768.3030209@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dzonatas Sol wrote: > I haven't ruled out the possibility of a faster interface than XML. > The approach I try to take it to make it work correctly and later > make it fast. Dzonatas, I think you should read these: http://c2.com/cgi/wiki?XmlAbuse http://www.ddj.com/architect/184414926 http://www.codinghorror.com/blog/archives/001114.html Please, use the right tool for the job. XML is useful for data definition, not as a network data transfer format. It is not an universal tool for this job and will make you hated by everyone who will need to deal with the XML decoding you have introduced. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKFydln11XseNj94gRArXOAJ4q5CoOOhRLGi2PJA7RBpb3xpz8SQCgl7/0 R3MtPa6nBxlrFUEKuWVVC3M= =Gtjf -----END PGP SIGNATURE----- From melinda at superliminal.com Fri May 22 16:12:14 2009 From: melinda at superliminal.com (Melinda Green) Date: Fri, 22 May 2009 16:12:14 -0700 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A171947.9050709@gmail.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> Message-ID: <4A17314E.10004@superliminal.com> Jan Ciger wrote: > Philip Rosedale wrote: > >> do we need to use any sort of XML intepreter? My preference would >> be simple UDP with the contents being a name/value pair: >> >> gesture/nod lookatPoint/100,100,100 >> >> etc. Seems important that this be extremely lightweight and fast. >> I'm a bit out of the loop, development wise, so maybe i'm wrong. Hm, I guess I missed that message. I have no opinion about the transport mechanism but I am concerned about mixing high-level gesture triggers with low-level look-at data. They seem to me to be two completely different messages being routed to two completely different systems. I would therefore advocate making them into two separate messages. -Melinda From monkowsk at watson.ibm.com Fri May 22 16:23:27 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri, 22 May 2009 19:23:27 -0400 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A171497.2000302@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> Message-ID: <4A1733EF.40306@watson.ibm.com> I think JSON, http://json.org is the leading standard name/value format. Philip Rosedale wrote: > do we need to use any sort of XML intepreter? My preference would be > simple UDP with the contents being a name/value pair: > > gesture/nod > lookatPoint/100,100,100 > > etc. Seems important that this be extremely lightweight and fast. I'm > a bit out of the loop, development wise, so maybe i'm wrong. > > P From philip at lindenlab.com Fri May 22 16:23:56 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Fri, 22 May 2009 16:23:56 -0700 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A171947.9050709@gmail.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> Message-ID: <4A17340C.4020202@lindenlab.com> Looks like DBus is TCP based - that still seems unneeded, I think we should use UDP, what think? Jan Ciger wrote: > XML is definitely an overkill and certainly shouldn't be used for > anything that has aspirations to be lightweight. > > Just use DBus - that is pretty standard and portable lightweight RPC > mechanism and it is in the viewer already - it is used for passing > slurls to the viewer from Linux browser. > > That would also allow easy scripting of the viewer in the future. > > Regards, > > Jan > From dzonatas at gmail.com Fri May 22 16:49:32 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 22 May 2009 16:49:32 -0700 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A172768.3030209@gmail.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> <4A171F90.1000007@gmail.com> <4A172768.3030209@gmail.com> Message-ID: <4A173A0C.4050407@gmail.com> Jan Ciger wrote: > XML is useful for data definition, The first two characters of the XML format, " in those two orders as a 16 bit value. ** If the either of those tests are true, then the data format is defined as UTF8 for further communication. * If either test false, then then the 16 bit value is test to see if it equals the UTF16 value for '<' or '?'. ** If the UTF16 value is true, then the communication is defined in UTF16 in network order. ** If false, the bytes are swapped and tested for a UTF16 '<' character *** If true, then the communication is defined in UTF16 in opposite of network order (hence, network order is already defined per platform implementation of endianess) * If neither of these are true, then UTF32 could be tested if desired. This is only needed to be done once per initial connection. Again, that sequence does exactly as you expected, which is to define the data format. You continue to say: * not as a network data transfer format. After a successful open tag, it is a pure dedicate network stream as, again, expected. You haven't shown it to do anything more or less than expected, and that is true with the interface and implemention kept distinct from each other. You also say: * I think you should read these What specifically do you want me to know? I started to read it and it quickly went into a wide range of arguments of why people go there to read it. Can you state your thesis? From dzonatas at gmail.com Fri May 22 17:01:00 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 22 May 2009 17:01:00 -0700 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A17340C.4020202@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> Message-ID: <4A173CBC.7070109@gmail.com> Just to get this started for a proof-of-concept, my I suggest whatever local system stream based format is available. Philip Rosedale wrote: > Looks like DBus is TCP based - that still seems unneeded, I think we > should use UDP, what think? > > Jan Ciger wrote: >> XML is definitely an overkill and certainly shouldn't be used for >> anything that has aspirations to be lightweight. >> >> Just use DBus - that is pretty standard and portable lightweight RPC >> mechanism and it is in the viewer already - it is used for passing >> slurls to the viewer from Linux browser. >> >> That would also allow easy scripting of the viewer in the future. >> >> Regards, >> >> Jan >> > From steve at lindenlab.com Fri May 22 17:05:55 2009 From: steve at lindenlab.com (Steve Bennetts) Date: Fri, 22 May 2009 17:05:55 -0700 Subject: [sldev] lltexturefetch.cpp patch for http-texture and/or snowglobe In-Reply-To: <4A119027.4010906@lindenlab.com> References: <493033a70905172331h33916268y84272e0fb7b08b2f@mail.gmail.com> <4A119027.4010906@lindenlab.com> Message-ID: <4A173DE3.4000209@lindenlab.com> We will be applying this patch next week, but if someone wants to play, I just discovered this major bug in lltexturefetch.cpp: void LLTextureFetchWorker::callbackDecoded(bool success, LLImageRaw* raw, LLImageRaw* aux) { + LLMutexLock lock(&mWorkMutex); ... The missing mutex lock here can cause all sorts of terrible artifacts. Don't know if this will fix everything, but it definitely addresses at least one of the crashes I have been seeing. -Steve From jan.ciger at gmail.com Fri May 22 17:35:36 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sat, 23 May 2009 02:35:36 +0200 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A17340C.4020202@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> Message-ID: <4A1744D8.1030208@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philip Rosedale wrote: > Looks like DBus is TCP based - that still seems unneeded, I think we > should use UDP, what think? UDP could work, however I do prefer a standard protocol over yet another homegrown one. TCP is not a big issue in this case - most common use case is a local server connecting to local viewer, so the latency reduction in the case of packet loss compared to TCP is going to be a non-issue. UDP will have little advantage here. On the other hand, with DBus you get lot of advantages with being able to script the viewer and call the APIs from other tools. With pure UDP you would have to redo the whole protocol implementation each time. Actually DBus uses Unix domain sockets, TCP and can use named pipes. Future versions will probably use also shared memory as a transport. However, DBus is intended for desktop scripting. That will work for an occasional function call to trigger an animation or set the camera. On the other hand, if you are anticipating streaming gobs of data (e.g. live position tracking from camera, 30 times/second), it is likely not the best choice - there I would go for VRPN (that is UDP-based). Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKF0TWn11XseNj94gRAohxAJ9CKC7/fr0mLeTqVs37qskwhLCBeACg1gJG c3NiYGl/Q4aJ6esVV2Boycs= =GrF8 -----END PGP SIGNATURE----- From dzonatas at gmail.com Fri May 22 18:06:28 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 22 May 2009 18:06:28 -0700 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A1744D8.1030208@gmail.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> <4A1744D8.1030208@gmail.com> Message-ID: <4A174C14.2020304@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090522/bb35d6f5/attachment.htm From tateru.nino at gmail.com Sat May 23 00:43:57 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat, 23 May 2009 17:43:57 +1000 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A17340C.4020202@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> Message-ID: <4A17A93D.4000103@gmail.com> In this case, you'll find that the functional difference between the two is negligible. If you were going off of the metal to another machine, that would be a bit different. For local use? UDP doesn't have an edge in this particular circumstance. Philip Rosedale wrote: > Looks like DBus is TCP based - that still seems unneeded, I think we > should use UDP, what think? > > Jan Ciger wrote: > >> XML is definitely an overkill and certainly shouldn't be used for >> anything that has aspirations to be lightweight. >> >> Just use DBus - that is pretty standard and portable lightweight RPC >> mechanism and it is in the viewer already - it is used for passing >> slurls to the viewer from Linux browser. >> >> That would also allow easy scripting of the viewer in the future. >> >> Regards, >> >> Jan >> >> > _______________________________________________ > 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/20090523/8a414d3f/attachment.htm From dzonatas at gmail.com Sat May 23 05:31:05 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Sat, 23 May 2009 05:31:05 -0700 Subject: [sldev] Gesture client code In-Reply-To: <4A17A93D.4000103@gmail.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> <4A17A93D.4000103@gmail.com> Message-ID: <4A17EC89.6000009@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090523/ef046ba5/attachment.htm From sllists at boroon.dasgupta.ch Sat May 23 13:27:40 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 23 May 2009 22:27:40 +0200 Subject: [sldev] [META] [HELP] HG and SVN Message-ID: <4A185C3C.4070208@boroon.dasgupta.ch> Hi all, Since at this time, the commits usually still happen on branches of http://svn.secondlife.com/svn/linden/ (or are snapshotted there from LL's internal subversion repository) and are only later merged over to the mercurial repositories at http://bitbucket.org/lindenlab/, I wondered if I could keep my clone of http://bitbucket.org/lindenlab/http-texture/ up to date by pulling changes from http://svn.secondlife.com/svn/linden/projects/2009/http-texture/. To do so, I executed > hg -v convert http://svn.secondlife.com/svn/linden/projects/2009/http-texture http-texture where ./http-texture contained a clone of http://bitbucket.org/lindenlab/http-texture/. This took quite long to finish. (In previous tries where I didn't use the -v option, I killed the process, because I thought it had crashed.) Fortunately, mercurial remembers what SVN revisions it already has for subsequent calls of hg convert. (Unfortunately, this info doesn't seem to get passed on when cloning.) What worries me now, is that this process not only created another head, but that the newly imported revisions don't seem to have common ancestors with the ones that were already in it. I've pushed the result to http://bitbucket.org/boroondas/snowglobe-svn2hg_test/. Note that http://bitbucket.org/boroondas/snowglobe-svn2hg_test/changeset/fc8054fad4b0/ doesn't have a parent. This problem didn't appear when I tested what would happen when merging two hg repositories that I had created independently of each other by converting the same SVN repo at different revisions. (Then again, that repository had much simpler content and history than LL's) Any ideas of what I could do differently? Also, what are the short-term plans (if any) for the repositories at http://bitbucket.org/lindenlab/? I guess they'll co-exist with LL's internal and public subversion repositories for quite some while, so will syncing between corresponding branches be automated during the transition? cheers Boroondas From sllists at boroon.dasgupta.ch Sat May 23 15:24:09 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 24 May 2009 00:24:09 +0200 Subject: [sldev] Give easybuild-2 a whirl In-Reply-To: <4A146057.5060507@lindenlab.com> References: <4A146057.5060507@lindenlab.com> Message-ID: <4A187789.2040800@boroon.dasgupta.ch> Rob Lanphier schrieb: > However, we'd appreciate it if the more adventurous among you would give > this branch a shot. Building looks fine on gentoo (tried the command line way), except I still have to delete the auto-downloaded libs mentioned in http://imprudenceviewer.org/wiki/How_to_compile#Removing_Bad_Libraries_on_Gentoo_Linux, but I have to do that for all CMake based SL branches, anyway. The resulting viewer seems to crash a bit more often than http://secondlife.com/developers/opensource/downloads/2009/http-texture/2283/SecondLife-i686-1.23.2.2283.tar.bz2. I guess not all recent fixes have been merged into easy-build-2 yet, have they? cheers Boroondas PS: Should we try out-of-source-tree builds, yet? If so, where should the libs and artwork archives be unpacked to? (I'd think to the build tree, not the source tree ... but what about the files outside of ./linden/indra/ ?) From lenglish5 at cox.net Sat May 23 16:29:59 2009 From: lenglish5 at cox.net (Lawson English) Date: Sat, 23 May 2009 16:29:59 -0700 Subject: [sldev] Anyone here with OpenCV experience? In-Reply-To: <4A15AEBC.7070800@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> Message-ID: <4A1886F7.8070007@cox.net> Philip Rosedale wrote: > Has anyone here worked with camera-based gesture recognition before? > How about OpenCV? Is OpenCV the best package for extracting basic head > position/gesture information from a camera image stream? Merov and I > are pondering a Snowglobe project to detect head motion from simple > cameras and connect it to the SL Viewer. > > Apple is rumored to be hiring engineers/programmers to incorporate such capabilities into the next-gen Mac OS X/iPhone systems and I would expect that Microsoft is also. Given this, the ability to interface with built-in resources should be a high priority for this and any other new SL i/o protocol. Lawson From feilen1000 at gmail.com Sat May 23 14:49:44 2009 From: feilen1000 at gmail.com (Feilen) Date: Sat, 23 May 2009 16:49:44 -0500 Subject: [sldev] Default FOV/FOV slider bar in graphics Message-ID: <4A186F78.4020203@gmail.com> I think that lowering the default FOV (field of view) whenever using SL makes it much more immersive, however it always resets back to the default. Could there be a way to keep the FOV when restarting SL or even a slider bar in the graphics tab? That would be much better for those with HMDs with a set FOV, which is much lower than the default (the one I'm planning on obtaining is 32?). From soft at lindenlab.com Sat May 23 16:51:32 2009 From: soft at lindenlab.com (Soft) Date: Sat, 23 May 2009 18:51:32 -0500 Subject: [sldev] Default FOV/FOV slider bar in graphics In-Reply-To: <4A186F78.4020203@gmail.com> References: <4A186F78.4020203@gmail.com> Message-ID: On Sat, May 23, 2009 at 4:49 PM, Feilen wrote: > I think that lowering the default FOV (field of view) whenever using SL > makes it much more immersive, however it always resets back to the > default. Could there be a way to keep the FOV when restarting SL or even > a slider bar in the graphics tab? That would be much better for those > with HMDs with a set FOV, which is much lower than the default (the one > I'm planning on obtaining is 32?). Your best approach would be filing a JIRA at http://jira.secondlife.com If you want to follow up with discussion, there's an sl-ux mailing list for UI discussions From melinda at superliminal.com Sun May 24 01:05:28 2009 From: melinda at superliminal.com (Melinda Green) Date: Sun, 24 May 2009 01:05:28 -0700 Subject: [sldev] Default FOV/FOV slider bar in graphics In-Reply-To: References: <4A186F78.4020203@gmail.com> Message-ID: <4A18FFC8.1010805@superliminal.com> Soft wrote: > On Sat, May 23, 2009 at 4:49 PM, Feilen wrote: > >> I think that lowering the default FOV (field of view) whenever using SL >> makes it much more immersive, however it always resets back to the >> default. Could there be a way to keep the FOV when restarting SL or even >> a slider bar in the graphics tab? That would be much better for those >> with HMDs with a set FOV, which is much lower than the default (the one >> I'm planning on obtaining is 32?). >> > > Your best approach would be filing a JIRA at http://jira.secondlife.com > > If you want to follow up with discussion, there's an sl-ux mailing > list for UI discussions No need to do that. I already implemented both of those things in 1.23 though the slider is on the Camera & Input tab. I find it funny that you want a narrower FOV because I was always wanting a wider one, also for reasons of immersivity. Using a 32? angle would look like you're wearing binoculars! Here's a great trick that took me ages to figure out: Make your main window use the full width of your screen. Then set the height to be roughly 1/2 of the width. Then set the FOV to be nearly 180?. Note that I also fixed the bugs where you could accidentally set view angles greater than 180? which would make a mess of your view. In 1.23 you can just set the slider all the way to the max or just hit ctrl-8 until it's maxed. Enjoy! -Melinda From merov at lindenlab.com Sun May 24 22:13:03 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Sun, 24 May 2009 22:13:03 -0700 Subject: [sldev] VWR-13511 : Occasional crashes in OpenJPEG Message-ID: <30C92864-9073-4285-A80E-5A76F591AECA@lindenlab.com> Hi guys, I've been digging through this problem and here are some data point and a plan of what we're intending to do: - Bundling kdu: we identified that, though we thought we were bundling the kdu libs with the snowglobe executables, we actually were not doing so because of a build script issue. CG identified the exact problem and will be fixing this shortly. This by itself will be "fixing" that bug for users downloading the builds. - OpenJPEG calls in the viewer: Dzonatas and Robin mentioned during the last Hippo meeting that there was one bug in the viewer wrt the use of the lib that we needed to fix (at least, that's what I understood). I'm all for making the fix (even if we'll be bundling kdu with the build, some of us prefer or need to run with OpenJPEG). I'd appreciate if someone would provide a patch that can be applied to the viewer code (or Robin can actually commit something). - OpenJPEG lib: Dzonatas provided some pointers to openjpeg patches in the JIRA but I don't really have the bandwidth right now to do this. Would someone volunteer to do whatever needs to be done on snowglobe to update OpenJPEG lib? - Performance: OpenJPEG vs KDU: I was curious to know what was the true difference between the 2 libraries wrt to decoding textures. I tried several ways of tracking this (which is tricky now with the new thread mechanism) and I eventually settled by tracking the pure decoding speed, adding time accumulation (and other measures) right when the library was called. I timed the use of openjpeg and kdu, verifying that dropping the kdu libs in the right place was enough to get it dynamically loaded and used by llimagej2c. Here's a selected output after using the viewer for a while with both libs: 2009-05-24T22:28:20Z INFO: init: J2C Engine is: OpenJPEG: 1.3.0, Runtime: 1.3.0 [...] 2009-05-24T22:32:44Z INFO: decode: Image decoding: completed blocks = 1460, partial block calls = 0, total decoded = 6.50681 MBytes 2009-05-24T22:32:44Z INFO: decode: speed = 0.238522 Mbytes/sec, or = 0.687382 Mpixels/sec 2009-05-25T03:49:51Z INFO: init: J2C Engine is: KDU [...] 2009-05-25T03:52:44Z INFO: decode: Image decoding: completed blocks = 1930, partial block calls = 0, total decoded = 6.49914 MBytes 2009-05-25T03:52:44Z INFO: decode: speed = 0.796175 Mbytes/sec, or = 2.95891 Mpixels/sec KDU is flat out 3 times faster to decode than OpenJPEG. The ratio is consistent throughout the whole session. Don't be too shocked about the decoding speed: this is *not* throughput of textures in the viewer. The data measures only the speed of decoding blocks of compressed images, making complete abstraction of network activity, object handling, etc... all things that are anyway identical in the 2 cases. The KDU viewer doesn't feel 3 times faster because, deep down, texture decoding is not the limiting factor that drive the perceived performance of the viewer. Still, in super texture heavy regions, I suppose this could make a difference. I'll attach a patch to the JIRA so others can try and improve the way I measured things. Cheers, - Merov From me at signpostmarv.name Sun May 24 22:23:51 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Mon, 25 May 2009 06:23:51 +0100 Subject: [sldev] VWR-13511 : Occasional crashes in OpenJPEG In-Reply-To: <30C92864-9073-4285-A80E-5A76F591AECA@lindenlab.com> References: <30C92864-9073-4285-A80E-5A76F591AECA@lindenlab.com> Message-ID: <4A1A2B67.6090904@signpostmarv.name> > KDU is flat out 3 times faster to decode than OpenJPEG. The ratio is > consistent throughout the whole session. > > Don't be too shocked about the decoding speed: this is *not* > throughput of textures in the viewer. The data measures only the speed > of decoding blocks of compressed images, making complete abstraction > of network activity, object handling, etc... all things that are > anyway identical in the 2 cases. The KDU viewer doesn't feel 3 times > faster because, deep down, texture decoding is not the limiting factor > that drive the perceived performance of the viewer. > > Still, in super texture heavy regions, I suppose this could make a > difference. > Since switching to Imprudence (which uses OpenJPEG), the difference seems negligible- though I don't explore as much as other people do. Do you have a "super texture heavy" region in mind that this can be checked in ? ~ Marv. -------------- 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/20090525/6990740a/attachment.bin From merov at lindenlab.com Sun May 24 22:48:36 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Sun, 24 May 2009 22:48:36 -0700 Subject: [sldev] VWR-13511 : Occasional crashes in OpenJPEG In-Reply-To: <4A1A2B67.6090904@signpostmarv.name> References: <30C92864-9073-4285-A80E-5A76F591AECA@lindenlab.com> <4A1A2B67.6090904@signpostmarv.name> Message-ID: <9EB64342-4203-4DBF-B672-A92B63F68B97@lindenlab.com> Hi, On May 24, 2009, at 10:23 PM, SignpostMarv Martin wrote: > Do you have a "super texture heavy" region in mind that this can be > checked in ? Nope, but I'm sure someone on the list will chime in with one SLURL :) Cheers, - Merov From missannotoole at yahoo.com Sun May 24 23:10:41 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Sun, 24 May 2009 23:10:41 -0700 (PDT) Subject: [sldev] VWR-13511 : Occasional crashes in OpenJPEG In-Reply-To: <4A1A2B67.6090904@signpostmarv.name> References: <30C92864-9073-4285-A80E-5A76F591AECA@lindenlab.com> <4A1A2B67.6090904@signpostmarv.name> Message-ID: <714950.99406.qm@web59104.mail.re1.yahoo.com> When I want to see what the impact of faster texture load code is I just clear cache and go stand in the landing of a region called "The Gor Hub". Last time I used the OSS compile I lasted about 5 minutes I think before it bombed out. Not even moving from the landing point. just turning in a circle. It is like a mall on steroids in a circular arrangement so it maximizes the number of textures presented in the FOV no matter in what direction you turn. You will see the difference. It is very noticeable What would be neat is a test harness to log the load times and load counts in each version and calculate the differences from a percentage of time factor (test harness add time, etc.) ________________________________ From: SignpostMarv Martin To: Philippe Bossut (Merov Linden) Cc: Second Life Developer Mailing List Sent: Monday, May 25, 2009 1:23:51 AM Subject: Re: [sldev] VWR-13511 : Occasional crashes in OpenJPEG > KDU is flat out 3 times faster to decode than OpenJPEG. The ratio is consistent throughout the whole session. > > Don't be too shocked about the decoding speed: this is *not* throughput of textures in the viewer. The data measures only the speed of decoding blocks of compressed images, making complete abstraction of network activity, object handling, etc... all things that are anyway identical in the 2 cases. The KDU viewer doesn't feel 3 times faster because, deep down, texture decoding is not the limiting factor that drive the perceived performance of the viewer. > > Still, in super texture heavy regions, I suppose this could make a difference. > Since switching to Imprudence (which uses OpenJPEG), the difference seems negligible- though I don't explore as much as other people do. Do you have a "super texture heavy" region in mind that this can be checked in ? ~ Marv. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090524/3a94db8e/attachment.htm From carlo at alinoe.com Mon May 25 04:13:27 2009 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 25 May 2009 13:13:27 +0200 Subject: [sldev] VWR-13511 : Occasional crashes in OpenJPEG In-Reply-To: <30C92864-9073-4285-A80E-5A76F591AECA@lindenlab.com> References: <30C92864-9073-4285-A80E-5A76F591AECA@lindenlab.com> Message-ID: <20090525111327.GA15256@alinoe.com> On Sun, May 24, 2009 at 10:13:03PM -0700, Philippe Bossut (Merov Linden) wrote: > - OpenJPEG calls in the viewer: Dzonatas and Robin mentioned during > the last Hippo meeting that there was one bug in the viewer wrt the > use of the lib that we needed to fix (at least, that's what I > understood). I'm all for making the fix (even if we'll be bundling kdu > with the build, some of us prefer or need to run with OpenJPEG). I'd > appreciate if someone would provide a patch that can be applied to the > viewer code (or Robin can actually commit something). If you are refering to one of the two bugs that I found in openjpeg, http://groups.google.com/group/openjpeg/browse_thread/thread/91c951104e184488 then no. This can only be *really* fixed in the openjpeg library. It already is fixed they told me, but I stopped tracking as I am simply using the latest SVN of openjpeg to build my viewer with. As I said before on this list, I believe that this only happens for corrupted images. -- Carlo Wood PS The other bug that I found was first reported here: http://groups.google.com/group/openjpeg/browse_thread/thread/4683bba9660c2779 Although later this turned out to not be a 64bit problem, but a general problem that will not be fixed until openjpeg 2.0. From carlo at alinoe.com Mon May 25 04:17:51 2009 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 25 May 2009 13:17:51 +0200 Subject: [sldev] VWR-13511 : Occasional crashes in OpenJPEG In-Reply-To: <714950.99406.qm@web59104.mail.re1.yahoo.com> References: <30C92864-9073-4285-A80E-5A76F591AECA@lindenlab.com> <4A1A2B67.6090904@signpostmarv.name> <714950.99406.qm@web59104.mail.re1.yahoo.com> Message-ID: <20090525111751.GB15256@alinoe.com> On Sun, May 24, 2009 at 11:10:41PM -0700, Ann Otoole wrote: > When I want to see what the impact of faster texture load code is I just clear > cache and go stand in the landing of a region called "The Gor Hub". > Last time I used the OSS compile I lasted about 5 minutes I think before it > bombed out. Not even moving from the landing point. just turning in a circle. Clearing the cache only will cause you to DOWNLOAD everything again. Of course that takes a long time. You should find a test where all the images are already in the cache, but not decoded yet. Does anyone know where I can find a description of how j2k decoding works in detail? If it is well documented, I might give it a try to write something really fast :/. -- Carlo Wood From dzonatas at gmail.com Mon May 25 08:11:17 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Mon, 25 May 2009 08:11:17 -0700 Subject: [sldev] VWR-13511 : Occasional crashes in OpenJPEG In-Reply-To: <30C92864-9073-4285-A80E-5A76F591AECA@lindenlab.com> References: <30C92864-9073-4285-A80E-5A76F591AECA@lindenlab.com> Message-ID: <4A1AB515.2030903@gmail.com> Philippe Bossut (Merov Linden) wrote: > KDU is flat out 3 times faster to decode than OpenJPEG. The ratio is > consistent throughout the whole session. > Until OpenJPEG v2, this 3x factor is simply due to the fact that KDU is able to pull metadata without any decode on any resolution level. The API for v1.x didn't have a call to extract just the header like the v2 of the API does. Therefore, at least up to 2x of that that 3x factor can be accounted for in time wasted to decode resolution levels when it didn't need to in order to just get metadata out of the header. Also, the default compile options on the OpenJPEG library does not have tree-vectorization optimization turned on. Without tree-vectorization, only a few picked areas of the code get SSE optimization. With tree-vectorization, the compiler will vectorize as much as it can as the code is written in a way to enable such tree-vectorization. Do note that tree-vectorization is not on by default because not everybody compiles with GCC, and MSVS did not support tree-vectorization. As for the metadata only mentioned above, that is fixed in OpenJPEG v2. From dzonatas at gmail.com Mon May 25 08:38:18 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Mon, 25 May 2009 08:38:18 -0700 Subject: [sldev] [Fwd: Re: VWR-13511 : Occasional crashes in OpenJPEG] Message-ID: <4A1ABB6A.7030700@gmail.com> There is also a note in the viewer source in llimage2jcoj.cpp that mentions the image being decoded entirely when only metadata is needed. I have a new version llimagej2coj.cpp that works with OpenJPEG v2 that only grabs the metadata and doesn't decode the entire image when only metadata is needed. -------------- next part -------------- An embedded message was scrubbed... From: Dzonatas Sol Subject: Re: [sldev] VWR-13511 : Occasional crashes in OpenJPEG Date: Mon, 25 May 2009 08:11:17 -0700 Size: 1799 Url: http://lists.secondlife.com/pipermail/sldev/attachments/20090525/d4a5a53f/attachment.eml From dzonatas at gmail.com Mon May 25 08:47:38 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Mon, 25 May 2009 08:47:38 -0700 Subject: [sldev] OpenJPEG v2 llimagej2coj.cpp patch *alpha* Message-ID: <4A1ABD9A.1050207@gmail.com> Here is the replacement llimagej2coj.cpp I mentioned earlier. I only used it to test the alpha version of OpenJPEG v2. This is only posted for those that just want to mess around with OpenJPEG v2. Any other OpenJPEG v2 comments should be directed to the openjpeg mail-list. -------------- next part -------------- A non-text attachment was scrubbed... Name: llimagej2cojv2.cpp Type: text/x-c++src Size: 15043 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090525/27279640/attachment.cpp From merov at lindenlab.com Mon May 25 14:23:00 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Mon, 25 May 2009 14:23:00 -0700 Subject: [sldev] OpenJPEG v2 llimagej2coj.cpp patch *alpha* In-Reply-To: <4A1ABD9A.1050207@gmail.com> References: <4A1ABD9A.1050207@gmail.com> Message-ID: Thanks Dzonatas, code is always very much appreciated :) Clearly, since OpenJPEG v2 is still alpha code, it is certainly too early to get that integrated in snowglobe but I created a JIRA to track that down the road: VWR-13699 It'll make easier also for folks on this list to grab your patch (attached to the JIRA) and add comments on their experimentation with v2. Cheers, - Merov On May 25, 2009, at 8:47 AM, Dzonatas Sol wrote: > Here is the replacement llimagej2coj.cpp I mentioned earlier. I only > used it to test the alpha version of OpenJPEG v2. This is only > posted for those that just want to mess around with OpenJPEG v2. Any > other OpenJPEG v2 comments should be directed to the openjpeg mail- > list. > > > /** > * @file llimagej2coj.cpp > * @brief This is an implementation of JPEG2000 encode/decode using > OpenJPEG. > * > * $LicenseInfo:firstyear=2006&license=viewergpl$ > * > * Copyright (c) 2006-2008, Linden Research, Inc. > * > * Second Life Viewer Source Code > * The source code in this file ("Source Code") is provided by Linden > Lab > * to you under the terms of the GNU General Public License, version > 2.0 > * ("GPL"), unless you have obtained a separate licensing agreement > * ("Other License"), formally executed by you and Linden Lab. Terms > of > * the GPL can be found in doc/GPL-license.txt in this distribution, or > * online at http://secondlifegrid.net/programs/open_source/licensing/gplv2 > * > * There are special exceptions to the terms and conditions of the > GPL as > * it is applied to this Source Code. View the full text of the > exception > * in the file doc/FLOSS-exception.txt in this software distribution, > or > * online at http://secondlifegrid.net/programs/open_source/licensing/flossexception > * > * By copying, modifying or distributing this software, you acknowledge > * that you have read and understood your obligations described above, > * and agree to abide by those obligations. > * > * ALL LINDEN LAB SOURCE CODE IS PROVIDED "AS IS." LINDEN LAB MAKES NO > * WARRANTIES, EXPRESS, IMPLIED OR OTHERWISE, REGARDING ITS ACCURACY, > * COMPLETENESS OR PERFORMANCE. > * $/LicenseInfo$ > */ > > /* Parts of this file is copyrighted by the OpenJPEG 2000 team. > Please is openjpeg.h include file for full copyright notice */ > > #include "linden_common.h" > #include "llimagej2coj.h" > > #define USE_OPJ_DEPRECATED > #include "openjpeg.h" > > #include "lltimer.h" > #include "llmemory.h" > > class OMVJ2KStream > { > U32 mStreamPosition ; > LLImageJ2C* mImageJ2C ; > > public: > opj_stream_t* stream; > > static OPJ_UINT32 _read (void * p_buffer, OPJ_UINT32 p_nb_bytes, > void * p_user_data) > { > return ((OMVJ2KStream*)p_user_data)->read( (U8*) p_buffer, (U32) > p_nb_bytes) ; > } > static OPJ_UINT32 _write (void * p_buffer, OPJ_UINT32 p_nb_bytes, > void * p_user_data) > { > return ((OMVJ2KStream*)p_user_data)->write((U8*) p_buffer, (U32) > p_nb_bytes) ; > } > static OPJ_SIZE_T _skip (OPJ_SIZE_T p_nb_bytes, void * p_user_data) > { > return ((OMVJ2KStream*)p_user_data)->skip((U32) p_nb_bytes) ; > } > static bool _seek (OPJ_SIZE_T p_nb_bytes, void * p_user_data) > { > return ((OMVJ2KStream*)p_user_data)->seek((U32) p_nb_bytes) ; > } > U32 read ( U8 * p_buffer, U32 p_nb_bytes) > { > if(!mImageJ2C->getData()) > return -1 ; > U32 bytes = p_nb_bytes ; > if( mStreamPosition + p_nb_bytes >= mImageJ2C->getDataSize() ) > { > if( mImageJ2C->getDataSize() <= mStreamPosition ) > return -1 ; > bytes = mImageJ2C->getDataSize() - mStreamPosition ; > } > memcpy( p_buffer, mImageJ2C->getData() + mStreamPosition, bytes ) ; > mStreamPosition += bytes ; > return bytes ; > } > U32 write( U8 * p_buffer, U32 p_nb_bytes) > { > S32 newpos = mStreamPosition + p_nb_bytes ; > if( !mImageJ2C->getData() ) > mImageJ2C->allocateData( (S32) p_nb_bytes ) ; > else if( newpos > mImageJ2C->getDataSize() ) > mImageJ2C->reallocateData( newpos ) ; > memcpy( mImageJ2C->getData() + mStreamPosition, p_buffer, > p_nb_bytes ); > mStreamPosition = newpos ; > return p_nb_bytes ; > } > U32 skip(U32 p_nb_bytes) // TODO: return value should be size_t, > yet opj defines it as U32 value for now > { > mStreamPosition += p_nb_bytes ; > return p_nb_bytes ; > } > bool seek(U32 p_nb_bytes) > { > mStreamPosition = p_nb_bytes ; > return true ; > } > OMVJ2KStream( bool writable, LLImageJ2C* llimagej2c ) > { > mStreamPosition = 0 ; > mImageJ2C = llimagej2c ; > > stream = opj_stream_create(J2K_STREAM_CHUNK_SIZE, writable); > > opj_stream_set_user_data(stream, this); > opj_stream_set_read_function(stream, _read); > opj_stream_set_write_function(stream, _write); > opj_stream_set_skip_function(stream, _skip); > opj_stream_set_seek_function(stream, _seek); > } > ~OMVJ2KStream() > { > opj_stream_destroy(stream); > } > }; > > const char* fallbackEngineInfoLLImageJ2CImpl() > { > static std::string version_string = > std::string("OpenJPEG: " OPENJPEG_VERSION ", Runtime: ") > + opj_version(); > return version_string.c_str(); > } > > LLImageJ2CImpl* fallbackCreateLLImageJ2CImpl() > { > return new LLImageJ2COJ(); > } > > void fallbackDestroyLLImageJ2CImpl(LLImageJ2CImpl* impl) > { > delete impl; > impl = NULL; > } > > /** > sample error callback expecting a LLFILE* client object > */ > void error_callback(const char* msg, void*) > { > // printf("[J2K] %s\n", msg) ; > lldebugs << "LLImageJ2CImpl error_callback: " << msg << llendl; > } > /** > sample warning callback expecting a LLFILE* client object > */ > void warning_callback(const char* msg, void*) > { > // printf("[J2K] %s\n", msg) ; > lldebugs << "LLImageJ2CImpl warning_callback: " << msg << llendl; > } > /** > sample debug callback expecting no client object > */ > void info_callback(const char* msg, void*) > { > // printf("[J2K] %s\n", msg) ; > lldebugs << "LLImageJ2CImpl info_callback: " << msg << llendl; > } > > > LLImageJ2COJ::LLImageJ2COJ() : LLImageJ2CImpl() > { > } > > > LLImageJ2COJ::~LLImageJ2COJ() > { > } > > > > BOOL LLImageJ2COJ::decodeImpl(LLImageJ2C &base, LLImageRaw > &raw_image, F32 decode_time, S32 first_channel, S32 max_channel_count) > { > // > // FIXME: Get the comment field out of the texture > // > > LLTimer decode_timer; > > opj_dparameters_t parameters; /* decompression parameters */ > opj_image_t *image = NULL; > > opj_codec_t* dinfo = NULL; /* handle to a decompressor */ > > OMVJ2KStream j2k( true, &base ) ; > > /* set decoding parameters to default values */ > opj_set_default_decoder_parameters(¶meters); > > parameters.cp_reduce = base.getRawDiscardLevel(); > > > /* get a decoder handle */ > dinfo = opj_create_decompress(CODEC_J2K); > > /* catch events using our callbacks and give a local context */ > opj_set_info_handler(dinfo, info_callback, NULL); > opj_set_warning_handler(dinfo, warning_callback, NULL); > opj_set_error_handler(dinfo, error_callback, NULL); > > /* setup the decoder decoding parameters using user parameters */ > opj_setup_decoder(dinfo, ¶meters); > > OPJ_INT32 x0, y0 ; > OPJ_UINT32 x1, y1, tiles_x, tiles_y; > > bool success = opj_read_header( dinfo, &image, &x0, &y0, &x1, &y1, > &tiles_x, &tiles_y, j2k.stream) ; > if(!success) > { > fprintf(stderr, "ERROR -> decodeImpl: failed to decode image > header!\n"); > if (image) > { > opj_image_destroy(image); > } > opj_destroy_codec(dinfo); > base.mDecoding = FALSE; > > return TRUE; // done > } > > image = opj_decode(dinfo, j2k.stream); > > if(!image) > { > opj_destroy_codec(dinfo); > raw_image.resize( x1/2, y1/2, 4); //TODO:DZ truncated data stream, > we set half size to signal there is more to read, and fill white/ > alpha. this is temporary, for openjpeg v2 alpha version > U8 *rawp = raw_image.getData(); > for (S32 y = ( (y1/2) - 1); y >= 0; y--) > { > for (S32 x = 0; x < (x1/2); x++) > { > *(rawp++) = 255; > *(rawp++) = 255; > *(rawp++) = 255; > *(rawp++) = 127; > } > } > return TRUE; > } > > opj_end_decompress(dinfo, j2k.stream); > // opj_destroy_codec(dinfo); > > > #if 0 > // sometimes we get bad data out of the cache - check to see if the > decode succeeded > int decompdifference = 0; > if (cinfo.numdecompos) // sanity > { > for (int comp = 0; comp < image->numcomps; comp++) > { /* get maximum decomposition level difference, first field is > from the COD header and the second > is what is actually met in the codestream, NB: if everything > was ok, this calculation will > return what was set in the cp_reduce value! */ > decompdifference = std::max(decompdifference, > cinfo.numdecompos[comp] - image->comps[comp].resno_decoded); > } > if (decompdifference < 0) // sanity > { > decompdifference = 0; > } > } > > /* if OpenJPEG failed to decode all requested decomposition levels > the difference will be greater than this level */ > if (decompdifference > base.getRawDiscardLevel()) > { > llwarns << "not enough data for requested discard level, setting > mDecoding to FALSE, difference: " << (decompdifference - > base.getRawDiscardLevel()) << llendl; > opj_image_destroy(image); > > base.mDecoding = FALSE; > return TRUE; > } > > if(image->numcomps <= first_channel) > { > // sanity > llwarns << "trying to decode more channels than are present in > image: numcomps: " << image->numcomps << " first_channel: " << > first_channel << llendl; > opj_destroy_cstr_info(&cinfo); > opj_image_destroy(image); > return TRUE; > } > #endif > // Copy image data into our raw image format (instead of the > separate channel format > > S32 img_components = image->numcomps ; > S32 channels = img_components - first_channel; > if( channels > max_channel_count ) > channels = max_channel_count; > > // Component buffers are allocated in an image width by height > buffer. > // The image placed in that buffer is ceil(width/2^factor) by > // ceil(height/2^factor) and if the factor isn't zero it will be at > the > // top left of the buffer with black filled in the rest of the > pixels. > // It is integer math so the formula is written in ceildivpo2. > // (Assuming all the components have the same width, height and > // factor.) > S32 comp_width = image->comps[0].w; > S32 f=image->comps[0].factor; > S32 width = ceildivpow2(image->x1 - image->x0, f); > S32 height = ceildivpow2(image->y1 - image->y0, f); > raw_image.resize(width, height, channels); > U8 *rawp = raw_image.getData(); > > > // first_channel is what channel to start copying from > // dest is what channel to copy to. first_channel comes from the > // argument, dest always starts writing at channel zero. > for (S32 comp = first_channel, dest=0; comp < first_channel + > channels; > comp++, dest++) > { > if (image->comps[comp].data) > { > S32 offset = dest; > for (S32 y = (height - 1); y >= 0; y--) > { > for (S32 x = 0; x < width; x++) > { > rawp[offset] = image->comps[comp].data[y*comp_width + x]; > offset += channels; > } > } > } > else // Some rare OpenJPEG versions have this bug. > { > fprintf(stderr, "ERROR -> decodeImpl: failed to decode image! > (NULL comp data - OpenJPEG bug)\n"); > opj_image_destroy(image); > opj_destroy_codec(dinfo); > > return TRUE; // done > } > } > > /* free opj data structures */ > opj_image_destroy(image); > opj_destroy_codec(dinfo); > > return TRUE; // done > } > > > BOOL LLImageJ2COJ::encodeImpl(LLImageJ2C &base, const LLImageRaw > &raw_image, const char* comment_text, F32 encode_time, BOOL > reversible) > { > const S32 MAX_COMPS = 5; > opj_cparameters_t parameters; /* compression parameters */ > > > /* set encoding parameters to default values */ > opj_set_default_encoder_parameters(¶meters); > parameters.cod_format = 0; > parameters.cp_disto_alloc = 1; > > if (reversible) > { > parameters.tcp_numlayers = 1; > parameters.tcp_rates[0] = 0.0f; > } > else > { > parameters.tcp_numlayers = 5; > parameters.tcp_rates[0] = 1920.0f; > parameters.tcp_rates[1] = 480.0f; > parameters.tcp_rates[2] = 120.0f; > parameters.tcp_rates[3] = 30.0f; > parameters.tcp_rates[4] = 10.0f; > parameters.irreversible = 1; > if (raw_image.getComponents() == 3) // TODO: if 4 comps and > opacity plane is fully opaque, then set mct=1 and numcomps=3 (drop > opacity plane), otherwise leave as mct=0 to favor rgb/spatial > instead of YUV > { > parameters.tcp_mct = 1; > } > } > > if (!comment_text) > { > parameters.cp_comment = (char *) ""; > } > else > { > // Awful hacky cast, too lazy to copy right now. > parameters.cp_comment = (char *) comment_text; > } > > // > // Fill in the source image from our raw image > // > OPJ_COLOR_SPACE color_space = CLRSPC_SRGB; > opj_image_cmptparm_t cmptparm[MAX_COMPS]; > opj_image_t * image = NULL; > S32 numcomps = raw_image.getComponents(); > S32 width = raw_image.getWidth(); > S32 height = raw_image.getHeight(); > > memset(&cmptparm[0], 0, MAX_COMPS * sizeof(opj_image_cmptparm_t)); > for(S32 c = 0; c < numcomps; c++) { > cmptparm[c].prec = 8; > cmptparm[c].bpp = 8; > cmptparm[c].sgnd = 0; > cmptparm[c].dx = parameters.subsampling_dx; > cmptparm[c].dy = parameters.subsampling_dy; > cmptparm[c].w = width; > cmptparm[c].h = height; > } > > /* create the image */ > image = opj_image_create(numcomps, &cmptparm[0], color_space); > > image->x1 = width; > image->y1 = height; > > S32 i = 0; > const U8 *src_datap = raw_image.getData(); > for (S32 y = height - 1; y >= 0; y--) > { > for (S32 x = 0; x < width; x++) > { > const U8 *pixel = src_datap + (y*width + x) * numcomps; > for (S32 c = 0; c < numcomps; c++) > { > image->comps[c].data[i] = *pixel; > pixel++; > } > i++; > } > } > > > > /* encode the destination image */ > /* ---------------------------- */ > > OMVJ2KStream j2k( false, &base ) ; > > /* get a J2K compressor handle */ > opj_codec_t* cinfo = opj_create_compress(CODEC_J2K); > > /* catch events using our callbacks and give a local context */ > opj_set_info_handler(cinfo, info_callback, NULL); > opj_set_warning_handler(cinfo, warning_callback, NULL); > opj_set_error_handler(cinfo, error_callback, NULL); > > /* setup the encoder parameters using the current image and using > user parameters */ > opj_setup_encoder(cinfo, ¶meters, image); > > > /* encode the image */ > /*if (*indexfilename) // If need to extract codestream > information > bSuccess = opj_encode_with_info(cinfo, cio, image, &cstr_info); > else*/ > bool bSuccess = opj_start_compress( cinfo, image, j2k.stream ); > bSuccess = bSuccess && opj_encode( cinfo, j2k.stream ); > bSuccess = bSuccess && opj_end_compress( cinfo, j2k.stream ); > > base.updateData(); // set width, height > > /* free remaining compression structures */ > opj_destroy_codec(cinfo); > > /* free user parameters structure */ > if(parameters.cp_matrice) free(parameters.cp_matrice); > > /* free image data */ > opj_image_destroy(image); > return TRUE; > } > > BOOL LLImageJ2COJ::getMetadata(LLImageJ2C &base) > { > // > // FIXME: We get metadata by decoding the ENTIRE image. > // > > // Update the raw discard level > base.updateRawDiscardLevel(); > > opj_dparameters_t parameters; /* decompression parameters */ > opj_image_t *image = NULL; > > opj_codec_t* dinfo = NULL; /* handle to a decompressor */ > > > /* set decoding parameters to default values */ > opj_set_default_decoder_parameters(¶meters); > > //parameters.cp_reduce = mRawDiscardLevel; > > /* decode the code-stream */ > /* ---------------------- */ > > /* JPEG-2000 codestream */ > OMVJ2KStream j2k( true, &base ) ; > > /* get a decoder handle */ > dinfo = opj_create_decompress(CODEC_J2K); > > /* catch events using our callbacks and give a local context */ > // opj_set_event_mgr((opj_common_ptr)dinfo, &event_mgr, stderr); > > /* setup the decoder decoding parameters using user parameters */ > opj_setup_decoder(dinfo, ¶meters); > > OPJ_INT32 x0, y0 ; > OPJ_UINT32 x1, y1, tiles_x, tiles_y; > > bool bResult = opj_read_header( dinfo, &image, &x0, &y0, &x1, &y1, > &tiles_x, &tiles_y, j2k.stream) ; > > // TODO:DZ try extract numcomps: if(! opj_read_tile_header( dinfo, > &l_tile_index, &l_data_size, &l_current_tile_x0, &l_current_tile_y0, > &l_current_tile_x1, &l_current_tile_y1, &l_nb_comps, &l_go_on, > j2k.stream)) > > /* free remaining structures */ > if(dinfo) > { > opj_destroy_codec(dinfo); > } > if(!bResult) > { > fprintf(stderr, "ERROR -> getMetadata: failed to decode image!\n"); > return FALSE; > } > > base.setSize( x1, y1, 4); > > return TRUE; > } > _______________________________________________ > 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 Mon May 25 20:13:40 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Mon, 25 May 2009 22:13:40 -0500 Subject: [sldev] [HELP] C++ newbie needs help with first compilation Message-ID: <4A1B5E64.3030502@dragonkeepcreations.com> I looked in the archives but didn't see anything helpful there, so here goes: I'd like to learn to tinker with the viewer source a bit, nothing major, just applying patches and such. I've followed the directions on the wiki and all seems fine until the "Building with CMake" step. It says to run a command line, but CMake doesn't have a command line, it's a GUI. Using the DOS prompt doesn't work. Randomly trying things made Visual Studio start compiling, but it spit out some errors, one of which was about a missing source file, fmod.h I believe it was. Can some one direct me to some more detailed instructions? Ones that don't assume the reader is already familiar with these programs? Environment: Windows XP Home CMake 2.6.4 Latest Cygwin Python 2.5 Windows SDK 6.1 DirectX SDK 9.24.1400 I set up Cygwin, CMake, and Python according to the directions. Thanks Maya Remblai From GordonWendt at gmail.com Mon May 25 21:07:24 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue, 26 May 2009 00:07:24 -0400 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <4A1B5E64.3030502@dragonkeepcreations.com> References: <4A1B5E64.3030502@dragonkeepcreations.com> Message-ID: <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> Which version of Visual Studio are you running? There are some great instructions on the wiki ( http://wiki.secondlife.com/wiki/Get_source_and_compile) but it'll be a lot easier to point you to a specific set of instructions and it'll save you a lot of time searching around for them. -Gordon Wendt On Mon, May 25, 2009 at 11:13 PM, Maya Remblai < snowfox102 at dragonkeepcreations.com> wrote: > I looked in the archives but didn't see anything helpful there, so here > goes: I'd like to learn to tinker with the viewer source a bit, nothing > major, just applying patches and such. I've followed the directions on > the wiki and all seems fine until the "Building with CMake" step. It > says to run a command line, but CMake doesn't have a command line, it's > a GUI. Using the DOS prompt doesn't work. Randomly trying things made > Visual Studio start compiling, but it spit out some errors, one of which > was about a missing source file, fmod.h I believe it was. Can some one > direct me to some more detailed instructions? Ones that don't assume the > reader is already familiar with these programs? > > Environment: > Windows XP Home > CMake 2.6.4 > Latest Cygwin > Python 2.5 > Windows SDK 6.1 > DirectX SDK 9.24.1400 > I set up Cygwin, CMake, and Python according to the directions. > > Thanks > Maya Remblai > _______________________________________________ > 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/20090526/a4465de5/attachment.htm From mrfrans at gmail.com Mon May 25 22:34:11 2009 From: mrfrans at gmail.com (Frans) Date: Tue, 26 May 2009 07:34:11 +0200 Subject: [sldev] Testing Snowglobe In-Reply-To: <0413542c5df56e13bf253fe917528d15@localhost> References: <4A15AC00.4050304@lindenlab.com> <0413542c5df56e13bf253fe917528d15@localhost> Message-ID: <7765f2c60905252234u16aee618p62845c608029704b@mail.gmail.com> Hi, I would be happy to do some tests as well. Regards, Frans On Fri, May 22, 2009 at 3:12 AM, Opensource Obscure wrote: > > On Thu, 21 May 2009 12:31:12 -0700, Rob Lanphier > wrote: > > Hi everyone, > > > > We have a number of test plans here: > > https://wiki.secondlife.com/wiki/Category:Test_Scripts > > > > If we could be assured that all of these tests were run in each > > development cycle, we could feel pretty good that Snowglobe has been put > > through the paces. Is this an activity that people here would be > > interested in helping out with if we could figure out the right way to > > coordinate the activity (e.g. avoiding duplication of effort, giving > > guidance on priority of testing, etc) > -- Jeroen Frans Virtual World Technology Specialist. TheVesuviusGroup.com SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090526/dcede670/attachment-0001.htm From snowfox102 at dragonkeepcreations.com Mon May 25 22:51:17 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Tue, 26 May 2009 00:51:17 -0500 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> References: <4A1B5E64.3030502@dragonkeepcreations.com> <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> Message-ID: <4A1B8355.70505@dragonkeepcreations.com> Oops sorry, I'm using Visual C++ 2008 Express 9.0. Also, I fixed the fmod issue, I had forgotten to copy a couple of the files to the right places. Still won't compile though, there are some other files missing that I haven't heard of. I'll post the exact messages tomorrow. Thanks, Maya Gordon Wendt wrote: > Which version of Visual Studio are you running? There are some great > instructions on the wiki > (http://wiki.secondlife.com/wiki/Get_source_and_compile) but it'll be > a lot easier to point you to a specific set of instructions and it'll > save you a lot of time searching around for them. > > -Gordon Wendt > > On Mon, May 25, 2009 at 11:13 PM, Maya Remblai > > wrote: > > I looked in the archives but didn't see anything helpful there, so > here > goes: I'd like to learn to tinker with the viewer source a bit, > nothing > major, just applying patches and such. I've followed the directions on > the wiki and all seems fine until the "Building with CMake" step. It > says to run a command line, but CMake doesn't have a command line, > it's > a GUI. Using the DOS prompt doesn't work. Randomly trying things made > Visual Studio start compiling, but it spit out some errors, one of > which > was about a missing source file, fmod.h I believe it was. Can some one > direct me to some more detailed instructions? Ones that don't > assume the > reader is already familiar with these programs? > > Environment: > Windows XP Home > CMake 2.6.4 > Latest Cygwin > Python 2.5 > Windows SDK 6.1 > DirectX SDK 9.24.1400 > I set up Cygwin, CMake, and Python according to the directions. > > Thanks > Maya Remblai > _______________________________________________ > 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 GordonWendt at gmail.com Mon May 25 23:17:05 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue, 26 May 2009 02:17:05 -0400 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <4A1B8355.70505@dragonkeepcreations.com> References: <4A1B5E64.3030502@dragonkeepcreations.com> <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> <4A1B8355.70505@dragonkeepcreations.com> Message-ID: <493033a70905252317v62b93866qa1a297c244bac309@mail.gmail.com> I'd suggest starting out by trying to follow the instructions at http://wiki.secondlife.com/wiki/Compiling_the_Viewer_(MSVS2008)although note the warning at the top of the page. I'm not sure if that's still relevant though. I wish you the best of luck btw, I have tried and failed several times on my attempts to build the viewer from scratch, the phrase "Abandon all hope all ye who enter here" is fitting. -Gordon Wendt On Tue, May 26, 2009 at 1:51 AM, Maya Remblai < snowfox102 at dragonkeepcreations.com> wrote: > Oops sorry, I'm using Visual C++ 2008 Express 9.0. > > Also, I fixed the fmod issue, I had forgotten to copy a couple of the > files to the right places. Still won't compile though, there are some > other files missing that I haven't heard of. I'll post the exact > messages tomorrow. > > Thanks, > Maya > > Gordon Wendt wrote: > > Which version of Visual Studio are you running? There are some great > > instructions on the wiki > > (http://wiki.secondlife.com/wiki/Get_source_and_compile) but it'll be > > a lot easier to point you to a specific set of instructions and it'll > > save you a lot of time searching around for them. > > > > -Gordon Wendt > > > > On Mon, May 25, 2009 at 11:13 PM, Maya Remblai > > > > wrote: > > > > I looked in the archives but didn't see anything helpful there, so > > here > > goes: I'd like to learn to tinker with the viewer source a bit, > > nothing > > major, just applying patches and such. I've followed the directions > on > > the wiki and all seems fine until the "Building with CMake" step. It > > says to run a command line, but CMake doesn't have a command line, > > it's > > a GUI. Using the DOS prompt doesn't work. Randomly trying things made > > Visual Studio start compiling, but it spit out some errors, one of > > which > > was about a missing source file, fmod.h I believe it was. Can some > one > > direct me to some more detailed instructions? Ones that don't > > assume the > > reader is already familiar with these programs? > > > > Environment: > > Windows XP Home > > CMake 2.6.4 > > Latest Cygwin > > Python 2.5 > > Windows SDK 6.1 > > DirectX SDK 9.24.1400 > > I set up Cygwin, CMake, and Python according to the directions. > > > > Thanks > > Maya Remblai > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090526/3546a834/attachment.htm From merov at lindenlab.com Tue May 26 00:16:23 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Tue, 26 May 2009 00:16:23 -0700 Subject: [sldev] Gesture client code In-Reply-To: <4A17EC89.6000009@gmail.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> <4A17A93D.4000103@gmail.com> <4A17EC89.6000009@gmail.com> Message-ID: <4FD852FF-3AA8-4404-B43D-33696A7A4611@lindenlab.com> Hi all, Gee! This is quite a thread! Thanks for all the suggestions, ideas and passion. As always, this community shows it's full of talented (and opiniated) people :) Since I'll be the guy tagged with driving/mentoring the intern on this project on a day to day basis, I'm taking on summarizing and answering some of the questions that surfaced in that thread (vaguely in chronological order): - Why OpenCV? As pointed out by folks, it may look like overkill for the goals currently stated but those are goals *a minima*. We sure hope to expand from this first experimentation since, it is indeed an experimental project. Jan Ciger confirmed though that, if the goal is to capture a wide set of face and body elements, OpenCV is a good starting point. - Emulate mouse/joystick driver? Several folks mentioned implicitly the parallel between capturing elements and emulating yet another kind of input device. The problem with mice or joysticks is that they have only one or few effectors and that those do not map on avatars controls. With a camera, we certainly want more than few effectors. Eventually, we'll rapidly grow to the point we want VR like richness for that input. VRPN in that respect is an interesting idea (thanks Jan again). Besides, we're not currently trying to "drive" the interaction (i.e. building prims or triggering camera movements and avatar navigation) but rather *add* to the currently rather canned (and unused) avatar animations (aka gestures) so to see how much of the RL emotional state we can share with other residents. IOW, we want to improve and add to the current experience, not replace or use as an alternative to keyboard, mouse, etc... - Gaze tracking: Often mentioned so that's certainly a misnomer in our case: we'd like to track "what the user is looking at" rather than "what the mouse is pointing to" (as it is today) but not to control the interaction as is the case with gaze tracking as understood in the field. Just share eye attention between residents. It'll be perfectly inconsequential then if the gaze of the user change to look outside the scene (or the screen), we'd just switch back to the current attitude and animation - VRwear (mentioned by Aimee): In my former incarnation, I shared a panel on Orange Island with those guys discussing avatar animation and puppeteering. Their video is great but, last I tried (more than 6 months ago) I couldn't get the demo to work at all (other experiences?). Note that apparently they've been modifying the viewer directly which is not a bad idea if you want to get results fast and put something in the hands of users (that's what I did with HandsFree3D). Developing a protocol (using RPC or UDP or the already existing VRPN) is more open and would actually allow those guys to focus on the image analysis and extraction rather than spending time tracking the various viewer releases. Although we would provide a first widely available incarnation of this, the architecture shouldn't prevent others (including commercial firms) to come up with their own wares (hardware and software) promising a better experience (may be specialized on some aspects: face, body, emotion, whatever...). There are a lot of players out there (GestureTek, Softkinetic, Mamoca to name a few) not to mention again the ones pointed to in that thread already. - Puppeteering: Since it's mentioned in the thread, just reminding people that I've been interested in that since some time (http://www.handsfree3d.com/ ) and provided a patch to fix the crashing puppeteering branch (VWR-7703). Let's just say that full body puppeteering is great, feasible in SL, but there are a lot of non-trivial problems, far trickier than driving a bunch of effectors for a game. Rigging (i.e. the mapping of user's movement to an avatar that is geometrically different) in particular is a pretty big (and pretty interesting) problem which is very much SL specific. - What are "gestures"? We were really thinking about "animations" ("gestures" are they are called in SL), i.e. triggering those without requiring the user to enter keyboard actions. This indeed would not require any server change as pointed out by Melinda. Sorry for the confusion Jan. Stopping there for now but we'll sure be coming with more info in the coming days. Cheers, - Merov From dzonatas at gmail.com Tue May 26 02:40:25 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Tue, 26 May 2009 02:40:25 -0700 Subject: [sldev] Gesture client code In-Reply-To: <4FD852FF-3AA8-4404-B43D-33696A7A4611@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> <4A17A93D.4000103@gmail.com> <4A17EC89.6000009@gmail.com> <4FD852FF-3AA8-4404-B43D-33696A7A4611@lindenlab.com> Message-ID: <4A1BB909.5070909@gmail.com> Attached is the basics of what is needed to get the gesture tracker to listen to a port and react. For now, I've left out the XML server socket bits and just cut it down to minimal code. The XML server socket works, I just don't want to confuse that with the request to simply read a UDP socket and react to a lookatPoint or gesture. (The XML server socket is my criteria) GestureTracker::init( LLPumpIO* ) is the entry starter. The questions I have so far are: * is this correct way to setup and use mLookAt and mLookAt->setLookAt() ? Also, not sure yet if it can be init'd when mainLoop() starts or only after login. * I didn't find yet what attention type the head motion should have, but I picked free-look. If the position is updated, then the attention timer is reset or does it still time out? Everything is tested except portions of the action() method. Cheers Philippe Bossut (Merov Linden) wrote: > Hi all, > > Gee! .... > -------------- next part -------------- A non-text attachment was scrubbed... Name: llgesturetracker.cpp Type: text/x-c++src Size: 2823 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090526/cf7798e3/attachment.cpp From jan.ciger at gmail.com Tue May 26 03:36:00 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Tue, 26 May 2009 12:36:00 +0200 Subject: [sldev] Gesture client code In-Reply-To: <4FD852FF-3AA8-4404-B43D-33696A7A4611@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> <4A17A93D.4000103@gmail.com> <4A17EC89.6000009@gmail.com> <4FD852FF-3AA8-4404-B43D-33696A7A4611@lindenlab.com> Message-ID: <4A1BC610.5000808@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philippe Bossut (Merov Linden) wrote: > Hi all, > > Gee! This is quite a thread! Thanks for all the suggestions, ideas > and passion. As always, this community shows it's full of talented > (and opiniated) people :) > As usual :) However, thanks for clarifying your intentions, Merov - it looks sensible. Feel free to contact me over any issues with OpenCV or VRPN - I am using these daily even in connection with SL and I am interested in seeing the viewer becoming a better prototyping platform for VR research. Not necessarily the same goal as you have, but I think that there is a plenty of technical overlap. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKG8YQn11XseNj94gRAk6BAJ0SaX2vCWh+ysguTmqjHdRJUPecsgCg8zs9 YxnPAb7p8SCP11/my04m/Xo= =yY5L -----END PGP SIGNATURE----- From jodiah at my-webhome.com Tue May 26 05:31:07 2009 From: jodiah at my-webhome.com (jodiah at my-webhome.com) Date: Tue, 26 May 2009 05:31:07 -0700 Subject: [sldev] [HELP] C++ newbie needs help with first compilation Message-ID: <20090526053107.8b0823960ceb6a56f7ddf638f99b00cb.6b0ff57f93.wbe@email.secureserver.net> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090526/2ad8691f/attachment.htm From moriz.gupte at gmail.com Tue May 26 07:02:32 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Tue, 26 May 2009 08:02:32 -0600 Subject: [sldev] Gesture client code In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> <4A16E5FC.6050403@lindenlab.com> <4A170D8B.1050404@gmail.com> <4A171497.2000302@lindenlab.com> <4A171947.9050709@gmail.com> <4A17340C.4020202@lindenlab.com> <4A17A93D.4000103@gmail.com> <4A17EC89.6000009@gmail.com> <4FD852FF-3AA8-4404-B43D-33696A7A4611@lindenlab.com> Message-ID: Hi Philippe, On Tue, May 26, 2009 at 1:16 AM, Philippe Bossut (Merov Linden) < merov at lindenlab.com> wrote: > Gaze tracking: Often mentioned so that's certainly a misnomer in our > case: we'd like to track "what the user is looking at" rather than > "what the mouse is pointing to" (as it is today) but not to control > the interaction as is the case with gaze tracking as understood in the > field. Just share eye attention between residents. > Always afraid to overload list, sorry guys..., > > OpenCV is a great start starting point because it will allow 'gaze > tracking' to also be more easily considered as the 'next thing'. Already > quite a few low cost cam OpenCV 'gaze tracking' based experimental solns out > there. On gaze= track mouse traditionally? Some of my work dealt with 'peer > gaze awareness' in shared spaces (well long time back..decade)--in one > strange case-I used gaze to browse dense auditory spaces..after the real > time gaze data was stabilized to filter out saccades...so in most cases IMHO > gaze was tracked for observational purposes from a HCI UI eval perspective > and awareness capture perspective..Gaze for manipulation (ie gaze to control > pointer) was more assistive tech stuff. > > I see Philip ruled out IR tracking right from the begining so dealing with > environmental conditions will be a hard problem... guess better solns could > come out from tougher constraints. So all is good, but even the Wii had to > ditch a non-IR solution. > > Reason why 'peer gaze awareness' is a big issue for collaboration, building > and otherwise... perceptual role taking, is that facial expressions (gaze > direction) and head orientations in many cases does not allow sensible > inferences to be made about the user behind the screen's attention space/ > attention focus. I see this every day in my work that requires shared > viewing of drawing boards, dioramas for emergency preparedness, equipment > and so forth.. > > Melinda suggested a few ways to deal with pointing and also did not > consider camsync to be of primary importance for the SL client. I went back > to drawing board and tried all kinds of ways to test these methods...lots of > findings here but afraid will appear off topic. > > Ramesh Ramloll > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090526/cfa2015d/attachment.htm From melinda at superliminal.com Tue May 26 09:24:52 2009 From: melinda at superliminal.com (Melinda Green) Date: Tue, 26 May 2009 09:24:52 -0700 Subject: [sldev] Gesture client code In-Reply-To: <4A1BB909.5070909@gmail.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> <4A17A93D.4000103@gmail.com> <4A17EC89.6000009@gmail.com> <4FD852FF-3AA8-4404-B43D-33696A7A4611@lindenlab.com> <4A1BB909.5070909@gmail.com> Message-ID: <4A1C17D4.3090601@superliminal.com> Dzonatas Sol wrote: > Attached is the basics of what is needed to get the gesture tracker to > listen to a port and react. For now, I've left out the XML server > socket bits and just cut it down to minimal code. The XML server > socket works, I just don't want to confuse that with the request to > simply read a UDP socket and react to a lookatPoint or gesture. (The > XML server socket is my criteria) > > GestureTracker::init( LLPumpIO* ) is the entry starter. > > The questions I have so far are: > > * is this correct way to setup and use mLookAt and > mLookAt->setLookAt() ? Also, not sure yet if it can be init'd when > mainLoop() starts or only after login. > * I didn't find yet what attention type the head motion should have, > but I picked free-look. If the position is updated, then the attention > timer is reset or does it still time out? I suspect we should add a new attention type specifically for head-tracking devices. Its default priority can be similar to free-look (I.E. low). I'm thinking that it should be just below free-look because it's inputs will be less "intentional" by the user. (Conscious attention should take precedence over unconscious attention.) I don't have the code in front of me but I expect the timer will reset with each effective input. It should be fine that these inputs come in almost continuously because assuming the priority is low enough, then these inputs will be easily overruled by higher priority attention inputs. -Melinda From steve at lindenlab.com Tue May 26 09:54:07 2009 From: steve at lindenlab.com (Steve Bennetts) Date: Tue, 26 May 2009 09:54:07 -0700 Subject: [sldev] lltexturefetch.cpp patch for http-texture and/or snowglobe In-Reply-To: <4A173DE3.4000209@lindenlab.com> References: <493033a70905172331h33916268y84272e0fb7b08b2f@mail.gmail.com><4A119027.4010906@lindenlab.com> <4A173DE3.4000209@lindenlab.com> Message-ID: <4A1C1EAF.5030002@lindenlab.com> So, adding that lock exposed a flaw in the logic resulting in a deadlock. Below is the fix for that. The problem was that LLTextureCache::update() was keeping the mutex protecting mReaders[] and mWriters[] locked while calling completed() in the responders, however readComplete() and writeComplete() (calls to which get triggered by the responders) do their own locking of the mutex, triggering the deadlock. There is no reason for the mutex to be locked while calling these completed() functions. -Steve Index: lltexturecache.cpp =================================================================== --- lltexturecache.cpp (revision 121571) +++ lltexturecache.cpp (revision 121572) @@ -779,6 +779,9 @@ } } + unlockWorkers(); + + // call 'completed' with workers list unlocked (may call readComplete() or writeComplete() for (responder_list_t::iterator iter1 = completed_list.begin(); iter1 != completed_list.end(); ++iter1) { @@ -787,8 +790,6 @@ responder->completed(success); } - unlockWorkers(); - return res; } Steve Bennetts wrote: > We will be applying this patch next week, but if someone wants to play, > I just discovered this major bug in lltexturefetch.cpp: > > void LLTextureFetchWorker::callbackDecoded(bool success, LLImageRaw* > raw, LLImageRaw* aux) > { > + LLMutexLock lock(&mWorkMutex); > > ... > > > The missing mutex lock here can cause all sorts of terrible artifacts. > Don't know if this will fix everything, but it definitely addresses at > least one of the crashes I have been seeing. > > -Steve > > > _______________________________________________ > 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 May 26 13:56:16 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 26 May 2009 13:56:16 -0700 Subject: [sldev] Testing sprint this week: Thursday, 2pm (normal OSS meeting time) Message-ID: <4A1C5770.3070906@lindenlab.com> Hi folks, As we discussed at last week's meeting, we'd like to have a QA sprint where we gather a lot of people to get broad coverage on the viewer in a short amount of time. Here's the tracking issue: http://jira.secondlife.com/browse/VWR-13640 I did a little work last week on a rough test plan here: https://wiki.secondlife.com/wiki/Snowglobe_Test_Plans/Test_Pass_1 ...which narrows the scope a little bit for testing to something we might be able to pull off in an hour. I've made this agenda for our meeting on Thursday: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda If this one is successful enough that we want to make it a regular event, we can plan for a secondary time to have it that doesn't clash with our existing meeting. Rob From sheet.spotter at gmail.com Tue May 26 18:13:19 2009 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Tue, 26 May 2009 20:13:19 -0500 Subject: [sldev] lltexturefetch.cpp patch for http-texture and/orsnowglobe In-Reply-To: <4A1C1EAF.5030002@lindenlab.com> References: <493033a70905172331h33916268y84272e0fb7b08b2f@mail.gmail.com><4A119027.4010906@lindenlab.com><4A173DE3.4000209@lindenlab.com> <4A1C1EAF.5030002@lindenlab.com> Message-ID: <7F6A7C22FBE24CF3B36B1FAF8F894D9F@kenb> The patch that Steve Linden provided resolves the deadlock I detailed in the comments of VWR-13437. The patch releases a mutex earlier, prior to making one of the calls that led to the deadlock. Releasing the mutex earlier eliminates that deadlock. Previously the HTTP-Texture viewer would hang on me after only a few minutes of moving my camera using Alt-Mouse. After manually applying the patch I have been unable to hang the viewer. Thank you Steve! Sheet Spotter -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Steve Bennetts Sent: May 26, 2009 11:54 AM To: Second Life Developer Mailing List Subject: Re: [sldev] lltexturefetch.cpp patch for http-texture and/orsnowglobe So, adding that lock exposed a flaw in the logic resulting in a deadlock. Below is the fix for that. The problem was that LLTextureCache::update() was keeping the mutex protecting mReaders[] and mWriters[] locked while calling completed() in the responders, however readComplete() and writeComplete() (calls to which get triggered by the responders) do their own locking of the mutex, triggering the deadlock. There is no reason for the mutex to be locked while calling these completed() functions. -Steve Index: lltexturecache.cpp =================================================================== --- lltexturecache.cpp (revision 121571) +++ lltexturecache.cpp (revision 121572) @@ -779,6 +779,9 @@ } } + unlockWorkers(); + + // call 'completed' with workers list unlocked (may call readComplete() or writeComplete() for (responder_list_t::iterator iter1 = completed_list.begin(); iter1 != completed_list.end(); ++iter1) { @@ -787,8 +790,6 @@ responder->completed(success); } - unlockWorkers(); - return res; } Steve Bennetts wrote: > We will be applying this patch next week, but if someone wants to play, > I just discovered this major bug in lltexturefetch.cpp: > > void LLTextureFetchWorker::callbackDecoded(bool success, LLImageRaw* > raw, LLImageRaw* aux) > { > + LLMutexLock lock(&mWorkMutex); > > ... > > > The missing mutex lock here can cause all sorts of terrible artifacts. > Don't know if this will fix everything, but it definitely addresses at > least one of the crashes I have been seeing. > > -Steve > > > _______________________________________________ > 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 Tue May 26 18:48:14 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Tue, 26 May 2009 18:48:14 -0700 Subject: [sldev] Gesture client code In-Reply-To: <4A1C17D4.3090601@superliminal.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> <4A17A93D.4000103@gmail.com> <4A17EC89.6000009@gmail.com> <4FD852FF-3AA8-4404-B43D-33696A7A4611@lindenlab.com> <4A1BB909.5070909@gmail.com> <4A1C17D4.3090601@superliminal.com> Message-ID: <4A1C9BDE.6000309@gmail.com> Melinda Green wrote: > Dzonatas Sol wrote: >> Attached is the basics of what is needed to get the gesture tracker >> to listen to a port and react. For now, I've left out the XML server >> socket bits and just cut it down to minimal code. The XML server >> socket works, I just don't want to confuse that with the request to >> simply read a UDP socket and react to a lookatPoint or gesture. (The >> XML server socket is my criteria) >> >> GestureTracker::init( LLPumpIO* ) is the entry starter. >> >> The questions I have so far are: >> >> * is this correct way to setup and use mLookAt and >> mLookAt->setLookAt() ? Also, not sure yet if it can be init'd when >> mainLoop() starts or only after login. >> * I didn't find yet what attention type the head motion should have, >> but I picked free-look. If the position is updated, then the >> attention timer is reset or does it still time out? > > I suspect we should add a new attention type specifically for > head-tracking devices. Its default priority can be similar to > free-look (I.E. low). I'm thinking that it should be just below > free-look because it's inputs will be less "intentional" by the user. > (Conscious attention should take precedence over unconscious > attention.) I don't have the code in front of me but I expect the > timer will reset with each effective input. It should be fine that > these inputs come in almost continuously because assuming the priority > is low enough, then these inputs will be easily overruled by higher > priority attention inputs. > > -Melinda > Thanks for the good info! I created a jira for the gesture tracker code: https://jira.secondlife.com/browse/VWR-13713 I added the C# program to send bytes to the UDP port, so now the reader/gesture-trigger/lookat code and the writer examples are there. From snowfox102 at dragonkeepcreations.com Tue May 26 21:40:41 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Tue, 26 May 2009 23:40:41 -0500 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> References: <4A1B5E64.3030502@dragonkeepcreations.com> <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> Message-ID: <4A1CC449.80101@dragonkeepcreations.com> Here's some of the errors VC++ is giving: 21>llmozlib2-vc80.lib(llembeddedbrowser.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\llmozlib2-vc80.lib' or at 'C:\SL_Dev\New\linden\indra\build-VC90\newview\RelWithDebInfo\vc80.pdb'; linking object as if no debug info 21>llmozlib2-vc80.lib(llembeddedbrowserwindow.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\llmozlib2-vc80.lib' or at 'C:\SL_Dev\New\linden\indra\build-VC90\newview\RelWithDebInfo\vc80.pdb'; linking object as if no debug info 21>llmozlib2-vc80.lib(llmozlib2.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\llmozlib2-vc80.lib' or at 'C:\SL_Dev\New\linden\indra\build-VC90\newview\RelWithDebInfo\vc80.pdb'; linking object as if no debug info 21>libndofdev.lib(ndofdev.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\libndofdev.lib' or at 'C:\SL_Dev\New\linden\indra\build-VC90\newview\RelWithDebInfo\vc80.pdb'; linking object as if no debug info 21>libndofdev.lib(ndofdev_win.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\libndofdev.lib' or at 'C:\SL_Dev\New\linden\indra\build-VC90\newview\RelWithDebInfo\vc80.pdb'; linking object as if no debug info Sometimes it appears to complete and tries to run the viewer, but gives this error: ERROR: LLAppViewer::initConfiguration: Cannot load default configuration file c:\SL_Dev\New\linden\indra\build-VC90\newview\app_settings\settings_files.xml Downloading an older version of CMake got past the command line problem, perhaps now I just need to delete all the compiled files and such and start over from scratch, now that I can actually get the python file to run. Still open to other tips though. Also, as I stated in my first message, I already did everything the wiki says. Maya From merov at lindenlab.com Tue May 26 22:13:11 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Tue, 26 May 2009 22:13:11 -0700 Subject: [sldev] lltexturefetch.cpp patch for http-textureand/orsnowglobe In-Reply-To: <7F6A7C22FBE24CF3B36B1FAF8F894D9F@kenb> References: <493033a70905172331h33916268y84272e0fb7b08b2f@mail.gmail.com><4A119027.4010906@lindenlab.com><4A173DE3.4000209@linden lab.com><4A1C1EAF.5030002@lindenlab.com> <7F6A7C22FBE24CF3B36B1FAF8F894D9F@kenb> Message-ID: Hi, Thanks for the feedback Sheet. This is great! I'm in the process of merging fixes from 1.23 as well as this and other fixes steve and bao did on http-texture. I'm planning to get the whole merge completed by tomorrow noon (I hit a couple of conflicts and broken unit tests I needed to fix). If all goes as planned, we should have that spiffy new build to play with for the test sprint Thursday :) Cheers, - Merov On May 26, 2009, at 6:13 PM, Sheet Spotter wrote: > The patch that Steve Linden provided resolves the deadlock I > detailed in the > comments of VWR-13437. > > The patch releases a mutex earlier, prior to making one of the calls > that > led to the deadlock. Releasing the mutex earlier eliminates that > deadlock. > > Previously the HTTP-Texture viewer would hang on me after only a few > minutes > of moving my camera using Alt-Mouse. After manually applying the > patch I > have been unable to hang the viewer. > > Thank you Steve! > > > Sheet Spotter > > -----Original Message----- > From: sldev-bounces at lists.secondlife.com > [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Steve > Bennetts > Sent: May 26, 2009 11:54 AM > To: Second Life Developer Mailing List > Subject: Re: [sldev] lltexturefetch.cpp patch for http-texture > and/orsnowglobe > > So, adding that lock exposed a flaw in the logic resulting in a > deadlock. Below is the fix for that. The problem was that > LLTextureCache::update() was keeping the mutex protecting mReaders[] > and > mWriters[] locked while calling completed() in the responders, however > readComplete() and writeComplete() (calls to which get triggered by > the > responders) do their own locking of the mutex, triggering the > deadlock. > There is no reason for the mutex to be locked while calling these > completed() functions. > > -Steve > > > Index: lltexturecache.cpp > =================================================================== > --- lltexturecache.cpp (revision 121571) > +++ lltexturecache.cpp (revision 121572) > @@ -779,6 +779,9 @@ > } > } > > + unlockWorkers(); > + > + // call 'completed' with workers list unlocked (may call > readComplete() or writeComplete() > for (responder_list_t::iterator iter1 = completed_list.begin(); > iter1 != completed_list.end(); ++iter1) > { > @@ -787,8 +790,6 @@ > responder->completed(success); > } > > - unlockWorkers(); > - > return res; > } > > > > Steve Bennetts wrote: >> We will be applying this patch next week, but if someone wants to >> play, >> I just discovered this major bug in lltexturefetch.cpp: >> >> void LLTextureFetchWorker::callbackDecoded(bool success, LLImageRaw* >> raw, LLImageRaw* aux) >> { >> + LLMutexLock lock(&mWorkMutex); >> >> ... >> >> >> The missing mutex lock here can cause all sorts of terrible >> artifacts. >> Don't know if this will fix everything, but it definitely addresses >> at >> least one of the crashes I have been seeing. >> >> -Steve >> >> >> _______________________________________________ >> 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 robin.cornelius at gmail.com Wed May 27 01:03:41 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed, 27 May 2009 09:03:41 +0100 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <4A1CC449.80101@dragonkeepcreations.com> References: <4A1B5E64.3030502@dragonkeepcreations.com> <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> <4A1CC449.80101@dragonkeepcreations.com> Message-ID: On Wed, May 27, 2009 at 5:40 AM, Maya Remblai wrote: > 21>llmozlib2-vc80.lib(llembeddedbrowser.obj) : warning LNK4099: PDB > 'vc80.pdb' was not > found with All these are just warnings that the debug database (.pdb) was not found for this library. Its not a problem. > Sometimes it appears to complete and tries to run the viewer, but gives > this error: > > ERROR: LLAppViewer::initConfiguration: Cannot load default configuration > file > c:\SL_Dev\New\linden\indra\build-VC90\newview\app_settings\settings_files.xml > You need to change the start up folder, right click on the secondlife-bin project, go to properties. Select debugging and in start up folder, click the browse icon and back up the tree until you are back in indra/ then select newview. note you will be by default in indra/build-vc90/newview/ eg the build area and not the source area. Robin From lenglish5 at cox.net Wed May 27 08:21:40 2009 From: lenglish5 at cox.net (Lawson English) Date: Wed, 27 May 2009 08:21:40 -0700 Subject: [sldev] Gesture client code In-Reply-To: <4FD852FF-3AA8-4404-B43D-33696A7A4611@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> <4A17A93D.4000103@gmail.com> <4A17EC89.6000009@gmail.com> <4FD852FF-3AA8-4404-B43D-33696A7A4611@lindenlab.com> Message-ID: <4A1D5A84.7030009@cox.net> Philippe Bossut (Merov Linden) wrote: > Hi all, > > Gee! This is quite a thread! Thanks for all the suggestions, ideas and > passion. As always, this community shows it's full of talented (and > opiniated) people :) > > Since I'll be the guy tagged with driving/mentoring the intern on this > project on a day to day basis, I'm taking on summarizing and answering > some of the questions that surfaced in that thread (vaguely in > chronological order): > [...] I know that Qwaq is further along than SL in this area. You might want to talk to them or to Croquet Hax in AW Groupies about what kind of work the OpenCroquet project has done along these lines. And for heaven's sake, youse guys got 400+ people that log into Groupies on a regular basis, many/most with highly technical backgrounds. Start a thread of discussion there in-world and see what ideas pop up. You might be pleasantly surprised. IM me (Saijanai Kuhn) in-world for an AW Groupies invite if you're not already a member. Lawson (Saijanai Kuhn ISL) From robla at lindenlab.com Wed May 27 11:25:31 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 27 May 2009 11:25:31 -0700 Subject: [sldev] Code review on first branding patch (VWR-13726) Message-ID: <4A1D859B.9040702@lindenlab.com> Hi folks, I've got a first branding patch for Snowglobe. http://jira.secondlife.com/browse/VWR-13726 This changes the taskbar icon, the titlebar name, and a few other places. A new "VIEWER_NAME" macro is introduced, but not used yet (saving for another patch suitable for merging into the main SL Viewer). Notes: I've only built/tested this on Linux. Rob From tayra.dagostino at gmail.com Wed May 27 12:42:06 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Wed, 27 May 2009 21:42:06 +0200 Subject: [sldev] [Snowglobe-automails] Crash stats 2009-05-26 (sliding one week window) In-Reply-To: <4A1C172B.3080200@lindenlab.com> References: <4A1C172B.3080200@lindenlab.com> Message-ID: <20090527214206.262bc344.tayra.dagostino@gmail.com> On Tue, 26 May 2009 09:22:03 -0700 Rob Lanphier wrote: > Weekend crash stats more than this kind of stats is possible have some stats about machine where viewer run? like CPU type, memory, video card chipset brand.... Reading http://secondlife.com/support/sysreqs.php i see minimum requirement for viewer is a P3-III, but i think no more people uses this uP. Long time ago somebody talk about enable SSE/SSE2 by default, I've tried both PN/SG/RC from linden and other linux viewer for the grid (with vectorization enabled), on same sim (relogging with same condition) fps and global rendering performance are visible... From merov at lindenlab.com Wed May 27 16:35:51 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Wed, 27 May 2009 16:35:51 -0700 Subject: [sldev] lltexturefetch.cpp patch for http-textureand/orsnowglobe In-Reply-To: References: <493033a70905172331h33916268y84272e0fb7b08b2f@mail.gmail.com><4A119027.4010906@lindenlab.com><4A173DE3.4000209@linden lab.com><4A1C1EAF.5030002@lindenlab.com><7F6A7C22FBE24CF3B36B1FAF8F894D9F@kenb> Message-ID: <17707CA1-E40E-48E7-8048-510DB2DF1525@lindenlab.com> Hi there, Just to let everybody know that the delicate "1.23 + http-texture" merge is completed and I migrated the result to projects/2009/http- texture (aka snowglobe). The builds completed successfully and you can now pick the results there: - Windows: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2324/Second_Life_1-23-2-2324_OSS_Setup.exe - Darwin: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2324/SecondLife_1_23_2_2324_OSS.dmg - Linux: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2324/SecondLife-i686-1.23.2.2324.tar.bz2 Those contain steve's patch plus a couple of other fixes he contributed internally over the weekend. Unless folks report catastrophic crashes, we'll be using those tomorrow during the test sprint. Cheers, - Merov On May 26, 2009, at 10:13 PM, Philippe Bossut (Merov Linden) wrote: > Hi, > > Thanks for the feedback Sheet. This is great! > > I'm in the process of merging fixes from 1.23 as well as this and > other fixes steve and bao did on http-texture. I'm planning to get the > whole merge completed by tomorrow noon (I hit a couple of conflicts > and broken unit tests I needed to fix). If all goes as planned, we > should have that spiffy new build to play with for the test sprint > Thursday :) > > Cheers, > - Merov > > On May 26, 2009, at 6:13 PM, Sheet Spotter wrote: > >> The patch that Steve Linden provided resolves the deadlock I >> detailed in the >> comments of VWR-13437. >> >> The patch releases a mutex earlier, prior to making one of the calls >> that >> led to the deadlock. Releasing the mutex earlier eliminates that >> deadlock. >> >> Previously the HTTP-Texture viewer would hang on me after only a few >> minutes >> of moving my camera using Alt-Mouse. After manually applying the >> patch I >> have been unable to hang the viewer. >> >> Thank you Steve! >> >> >> Sheet Spotter >> >> -----Original Message----- >> From: sldev-bounces at lists.secondlife.com >> [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Steve >> Bennetts >> Sent: May 26, 2009 11:54 AM >> To: Second Life Developer Mailing List >> Subject: Re: [sldev] lltexturefetch.cpp patch for http-texture >> and/orsnowglobe >> >> So, adding that lock exposed a flaw in the logic resulting in a >> deadlock. Below is the fix for that. The problem was that >> LLTextureCache::update() was keeping the mutex protecting mReaders[] >> and >> mWriters[] locked while calling completed() in the responders, >> however >> readComplete() and writeComplete() (calls to which get triggered by >> the >> responders) do their own locking of the mutex, triggering the >> deadlock. >> There is no reason for the mutex to be locked while calling these >> completed() functions. >> >> -Steve >> >> >> Index: lltexturecache.cpp >> =================================================================== >> --- lltexturecache.cpp (revision 121571) >> +++ lltexturecache.cpp (revision 121572) >> @@ -779,6 +779,9 @@ >> } >> } >> >> + unlockWorkers(); >> + >> + // call 'completed' with workers list unlocked (may call >> readComplete() or writeComplete() >> for (responder_list_t::iterator iter1 = completed_list.begin(); >> iter1 != completed_list.end(); ++iter1) >> { >> @@ -787,8 +790,6 @@ >> responder->completed(success); >> } >> >> - unlockWorkers(); >> - >> return res; >> } >> >> >> >> Steve Bennetts wrote: >>> We will be applying this patch next week, but if someone wants to >>> play, >>> I just discovered this major bug in lltexturefetch.cpp: >>> >>> void LLTextureFetchWorker::callbackDecoded(bool success, LLImageRaw* >>> raw, LLImageRaw* aux) >>> { >>> + LLMutexLock lock(&mWorkMutex); >>> >>> ... >>> >>> >>> The missing mutex lock here can cause all sorts of terrible >>> artifacts. >>> Don't know if this will fix everything, but it definitely addresses >>> at >>> least one of the crashes I have been seeing. >>> >>> -Steve >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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/20090527/1e9efa6c/attachment.htm From philip at lindenlab.com Wed May 27 17:38:08 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Wed, 27 May 2009 17:38:08 -0700 Subject: [sldev] lltexturefetch.cpp patch for http-textureand/orsnowglobe In-Reply-To: <17707CA1-E40E-48E7-8048-510DB2DF1525@lindenlab.com> References: <493033a70905172331h33916268y84272e0fb7b08b2f@mail.gmail.com><4A119027.4010906@lindenlab.com><4A173DE3.4000209@linden lab.com><4A1C1EAF.5030002@lindenlab.com><7F6A7C22FBE24CF3B36B1FAF8F894D9F@kenb> <17707CA1-E40E-48E7-8048-510DB2DF1525@lindenlab.com> Message-ID: <4A1DDCF0.90400@lindenlab.com> Cool stuff - can't crash it yet! It would be great if as many people as possible can give this a try and see how it runs. See folks in the thursday meeting where we can test it some more. Philip Philippe Bossut (Merov Linden) wrote: > Hi there, > > Just to let everybody know that the delicate "1.23 + http-texture" merge > is completed and I migrated the result to projects/2009/http-texture > (aka snowglobe). The builds completed successfully and you can now pick > the results there: > - > Windows: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2324/Second_Life_1-23-2-2324_OSS_Setup.exe > - > Darwin: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2324/SecondLife_1_23_2_2324_OSS.dmg > - > Linux: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2324/SecondLife-i686-1.23.2.2324.tar.bz2 > > Those contain steve's patch plus a couple of other fixes he contributed > internally over the weekend. > > Unless folks report catastrophic crashes, we'll be using those tomorrow > during the test sprint. > > Cheers, > - Merov > > On May 26, 2009, at 10:13 PM, Philippe Bossut (Merov Linden) wrote: > >> Hi, >> >> Thanks for the feedback Sheet. This is great! >> >> I'm in the process of merging fixes from 1.23 as well as this and >> other fixes steve and bao did on http-texture. I'm planning to get the >> whole merge completed by tomorrow noon (I hit a couple of conflicts >> and broken unit tests I needed to fix). If all goes as planned, we >> should have that spiffy new build to play with for the test sprint >> Thursday :) >> >> Cheers, >> - Merov >> >> On May 26, 2009, at 6:13 PM, Sheet Spotter wrote: >> >>> The patch that Steve Linden provided resolves the deadlock I >>> detailed in the >>> comments of VWR-13437. >>> >>> The patch releases a mutex earlier, prior to making one of the calls >>> that >>> led to the deadlock. Releasing the mutex earlier eliminates that >>> deadlock. >>> >>> Previously the HTTP-Texture viewer would hang on me after only a few >>> minutes >>> of moving my camera using Alt-Mouse. After manually applying the >>> patch I >>> have been unable to hang the viewer. >>> >>> Thank you Steve! >>> >>> >>> Sheet Spotter >>> >>> -----Original Message----- >>> From: sldev-bounces at lists.secondlife.com >>> >>> [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Steve >>> Bennetts >>> Sent: May 26, 2009 11:54 AM >>> To: Second Life Developer Mailing List >>> Subject: Re: [sldev] lltexturefetch.cpp patch for http-texture >>> and/orsnowglobe >>> >>> So, adding that lock exposed a flaw in the logic resulting in a >>> deadlock. Below is the fix for that. The problem was that >>> LLTextureCache::update() was keeping the mutex protecting mReaders[] >>> and >>> mWriters[] locked while calling completed() in the responders, however >>> readComplete() and writeComplete() (calls to which get triggered by >>> the >>> responders) do their own locking of the mutex, triggering the >>> deadlock. >>> There is no reason for the mutex to be locked while calling these >>> completed() functions. >>> >>> -Steve >>> >>> >>> Index: lltexturecache.cpp >>> =================================================================== >>> --- lltexturecache.cpp (revision 121571) >>> +++ lltexturecache.cpp (revision 121572) >>> @@ -779,6 +779,9 @@ >>> } >>> } >>> >>> + unlockWorkers(); >>> + >>> + // call 'completed' with workers list unlocked (may call >>> readComplete() or writeComplete() >>> for (responder_list_t::iterator iter1 = completed_list.begin(); >>> iter1 != completed_list.end(); ++iter1) >>> { >>> @@ -787,8 +790,6 @@ >>> responder->completed(success); >>> } >>> >>> - unlockWorkers(); >>> - >>> return res; >>> } >>> >>> >>> >>> Steve Bennetts wrote: >>>> We will be applying this patch next week, but if someone wants to >>>> play, >>>> I just discovered this major bug in lltexturefetch.cpp: >>>> >>>> void LLTextureFetchWorker::callbackDecoded(bool success, LLImageRaw* >>>> raw, LLImageRaw* aux) >>>> { >>>> + LLMutexLock lock(&mWorkMutex); >>>> >>>> ... >>>> >>>> >>>> The missing mutex lock here can cause all sorts of terrible >>>> artifacts. >>>> Don't know if this will fix everything, but it definitely addresses >>>> at >>>> least one of the crashes I have been seeing. >>>> >>>> -Steve >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 twisted_laws at hotmail.com Wed May 27 18:05:23 2009 From: twisted_laws at hotmail.com (Twisted Laws) Date: Wed, 27 May 2009 21:05:23 -0400 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: References: Message-ID: Very cool! This build of Second Life 1.23.2 (2324) May 27 2009 15:28:41 (Second Life OSS) is most excellent! I've been running for quite some time and no real issues :) I resolved my jira http://jira.secondlife.com/browse/VWR-13437 as I can no longer duplicate the problem. _________________________________________________________________ Hotmail? has a new way to see what's up with your friends. http://windowslive.com/Tutorial/Hotmail/WhatsNew?ocid=TXT_TAGLM_WL_HM_Tutorial_WhatsNew1_052009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090527/9ccf44b5/attachment-0001.htm From melinda at superliminal.com Wed May 27 19:11:08 2009 From: melinda at superliminal.com (Melinda Green) Date: Wed, 27 May 2009 19:11:08 -0700 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: References: Message-ID: <4A1DF2BC.2000200@superliminal.com> Twisted Laws wrote: > Very cool! This build of Second Life 1.23.2 (2324) May 27 2009 > 15:28:41 (Second Life OSS) is most excellent! I've been running for > quite some time and no real issues :) I resolved my jira > http://jira.secondlife.com/browse/VWR-13437 as I can no longer > duplicate the problem. I was not so lucky as it blue-screened for me on start-up! I never had that happen before that I recall. It hung for a long time on the "clearing cache" step and then blue-screened. On restarting, I was able to run Snowglobe just fine though I keep getting system messages about the "name.cache" file being corrupt and unreadable and that I should run chkdsk. :~( I think I'll try uninstall/reinstall instead and see if that helps. Below is the text of the Windows Event Viewer data on the event. -Melinda ________________EVENT LOG____________________ Fault bucket 586117558, type 5 Event Name: RADAR_PRE_LEAK_32 Response: Not available Cab Id: 0 Problem signature: P1: SecondLifeOSS.exe P2: 1.23.2.2324 P3: 6.1.7000.2.0.0 P4: P5: P6: P7: P8: P9: P10: Attached files: C:\Users\Melinda\AppData\Local\Temp\RDR7696.tmp\empty.txt These files may be available here: Analysis symbol: Rechecking for solution: 0 Report Id: Report Status: 0 ________________HELP ABOUT DATA______________________ Second Life 1.23.2 (2324) May 27 2009 15:28:41 (Second Life OSS) Release Notes Built with MSVC version 1400 You are at 257338.0, 288092.9, 39.8 in Vineland located at sim295.agni.lindenlab.com (216.82.12.171:13003) Second Life Server 1.26.4.120562 Release Notes CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (2393 MHz) Memory: 3582 MB OS Version: Professional (Build 7000) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 8600M GT/PCI/SSE2 Windows Graphics Driver Version: 7.15.0011.0143 OpenGL Version: 2.1.1 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.24220 (Mozilla GRE version 1.8.1.21_0000000000) Packets Lost: 0/1338 (0.0%) From andromedaquonset at gmail.com Thu May 28 03:03:12 2009 From: andromedaquonset at gmail.com (Andromeda Quonset) Date: Thu, 28 May 2009 04:03:12 -0600 Subject: [sldev] lltexturefetch.cpp patch for http-textureand/orsnowglobe In-Reply-To: <4A1DDCF0.90400@lindenlab.com> References: <493033a70905172331h33916268y84272e0fb7b08b2f@mail.gmail.com> <4A119027.4010906@lindenlab.com> <4A173DE3.4000209@linden lab.com> <4A1C1EAF.5030002@lindenlab.com> <7F6A7C22FBE24CF3B36B1FAF8F894D9F@kenb> <17707CA1-E40E-48E7-8048-510DB2DF1525@lindenlab.com> <4A1DDCF0.90400@lindenlab.com> Message-ID: <4a1e60e0.20038e0a.1d49.ffffc9f2@mx.google.com> I was using the Windows compile of it earlier, and it seemed to be OK, but after a brief period I was "summoned" to do some security work, and found I was unable to ban some griefers. That led to a discovery that there were issues with the parcel I was on reporting it belonged to one group, when it actually belonged to another group. Re-logging to the viewer I normally used had the parcel reporting the correct group, and I was able to do some of the banning I needed. There could be other issues in this viewer, so I am going to have to suspend testing of it since I am called upon to do banning more often than I wish. Andromeda At 06:38 PM 5/27/2009, you wrote: >Cool stuff - can't crash it yet! It would be great if as many people as >possible can give this a try and see how it runs. See folks in the >thursday meeting where we can test it some more. > >Philip > >Philippe Bossut (Merov Linden) wrote: > > Hi there, > > > > Just to let everybody know that the delicate "1.23 + http-texture" merge > > is completed and I migrated the result to projects/2009/http-texture > > (aka snowglobe). The builds completed successfully and you can now pick > > the results there: From mrfrans at gmail.com Thu May 28 07:15:52 2009 From: mrfrans at gmail.com (Frans) Date: Thu, 28 May 2009 16:15:52 +0200 Subject: [sldev] lltexturefetch.cpp patch for http-textureand/orsnowglobe In-Reply-To: <4a1e60e0.20038e0a.1d49.ffffc9f2@mx.google.com> References: <493033a70905172331h33916268y84272e0fb7b08b2f@mail.gmail.com> <4A119027.4010906@lindenlab.com> <4A1C1EAF.5030002@lindenlab.com> <7F6A7C22FBE24CF3B36B1FAF8F894D9F@kenb> <17707CA1-E40E-48E7-8048-510DB2DF1525@lindenlab.com> <4A1DDCF0.90400@lindenlab.com> <4a1e60e0.20038e0a.1d49.ffffc9f2@mx.google.com> Message-ID: <7765f2c60905280715kb4a5689l4bdd9b8a0724acd@mail.gmail.com> Could that have been a grid issue, not sending you the parcel info in time? I know I have seen that update a bit sluggish. On Thu, May 28, 2009 at 12:03 PM, Andromeda Quonset < andromedaquonset at gmail.com> wrote: > I was using the Windows compile of it earlier, and it seemed to be > OK, but after a brief period I was "summoned" to do some security > work, and found I was unable to ban some griefers. That led to a > discovery that there were issues with the parcel I was on reporting > it belonged to one group, when it actually belonged to another > group. Re-logging to the viewer I normally used had the parcel > reporting the correct group, and I was able to do some of the banning > I needed. There could be other issues in this viewer, so I am going > to have to suspend testing of it since I am called upon to do banning > more often than I wish. > > Andromeda > -- Jeroen Frans Virtual World Technology Specialist. TheVesuviusGroup.com SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090528/f050d692/attachment.htm From tinselsilvera at frontiernet.net Thu May 28 12:23:37 2009 From: tinselsilvera at frontiernet.net (tinselsilvera at frontiernet.net) Date: Thu, 28 May 2009 19:23:37 +0000 (UTC) Subject: [sldev] Yeah for Second Life 1.23.2 (2324) Message-ID: <1268108819.2932861243538617845.JavaMail.root@cl05-host03.roch.ny.frontiernet.net> A yeah for me as well! I've been using it for the past two days with no issues to report. The map is loading quicker and the places/textures seem to be loading quicker as well. Good job everyone! -- Tinsel Silvera Virtual Worlds Traveler http://tinselsilvera.blogspot.com/ From zha.ewry at gmail.com Thu May 28 12:30:27 2009 From: zha.ewry at gmail.com (Zha Ewry) Date: Thu, 28 May 2009 15:30:27 -0400 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <4A1DF2BC.2000200@superliminal.com> References: <4A1DF2BC.2000200@superliminal.com> Message-ID: <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> This appears to be the most stable OSS build I've played with yet. Is it actually using the HTTP texture fetch path to main grid regions? From john at bangor.ac.uk Thu May 28 12:51:41 2009 From: john at bangor.ac.uk (C J Owen) Date: Thu, 28 May 2009 20:51:41 +0100 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> References: <4A1DF2BC.2000200@superliminal.com> <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> Message-ID: <4A1EEB4D.1000306@bangor.ac.uk> Very stable build, I can't crash it either. I am though seeing some textures remaining fuzzy. Texture console says all have downloaded, but they are remaining partially rendered. (gave them 10 minutes before sending this, still not loaded) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GTX 295/PCI/SSE2 Windows Graphics Driver Version: 7.15.0011.8250 Generally though, all textures that *do* load are doing so faster. John. From merov at lindenlab.com Thu May 28 12:53:35 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 28 May 2009 12:53:35 -0700 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> References: <4A1DF2BC.2000200@superliminal.com> <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> Message-ID: <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> Hi Zha, On May 28, 2009, at 12:30 PM, Zha Ewry wrote: > This appears to be the most stable OSS build I've played with yet. Is > it actually using the HTTP texture fetch path to main grid regions? Yes and no: it's using the new threaded fetch mechanism (yes part) but it's not using http to fetch them (no part). The only part that is using http to fetch jpeg textures right now is the viewer's map. Cheers, - Merov From lenglish5 at cox.net Thu May 28 13:28:56 2009 From: lenglish5 at cox.net (Lawson English) Date: Thu, 28 May 2009 13:28:56 -0700 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> References: <4A1DF2BC.2000200@superliminal.com> <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> Message-ID: <4A1EF408.7010409@cox.net> Philippe Bossut (Merov Linden) wrote: > Hi Zha, > > On May 28, 2009, at 12:30 PM, Zha Ewry wrote: > >> This appears to be the most stable OSS build I've played with yet. Is >> it actually using the HTTP texture fetch path to main grid regions? >> > > Yes and no: it's using the new threaded fetch mechanism (yes part) but > it's not using http to fetch them (no part). > > The only part that is using http to fetch jpeg textures right now is > the viewer's map. > > Cheers, > - Merov > _______________________________________________ > There was a discussion today in one of the scripter's groups about accessing the map textures from LSL. Will it be/is it possible to use the http texture URLs directly from LSL to put the maps in-world? Lawson From merov at lindenlab.com Thu May 28 13:41:30 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 28 May 2009 13:41:30 -0700 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <4A1EF408.7010409@cox.net> References: <4A1DF2BC.2000200@superliminal.com> <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> <4A1EF408.7010409@cox.net> Message-ID: Hi Lawson, On May 28, 2009, at 1:28 PM, Lawson English wrote: > There was a discussion today in one of the scripter's groups about > accessing the map textures from LSL. Will it be/is it > possible to use the http texture URLs directly from LSL to put the > maps in-world? I'm not an LSL scripter but my understanding is that you cannot fetch asset using http get in LSL (for plenty of reason including security). As such, it's not possible to fetch map tiles from LSL. That being said, the map tiles organization and access methods are publicly documented on the wiki: https://wiki.secondlife.com/wiki/Webmap_AP The way to build the http string to access the map tile you want is specifically described here: https://wiki.secondlife.com/wiki/ Webmap_API#Accessing_map_images_directly Cheers, - Merov From john at bangor.ac.uk Thu May 28 14:29:06 2009 From: john at bangor.ac.uk (C J Owen) Date: Thu, 28 May 2009 22:29:06 +0100 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: References: <4A1DF2BC.2000200@superliminal.com> <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> <4A1EF408.7010409@cox.net> Message-ID: <4A1F0222.6030801@bangor.ac.uk> Addendum to my previous message. The map now loads ridiculously fast, an order of magnitude over non http fetch. This is *very* impressive. From missannotoole at yahoo.com Thu May 28 15:29:22 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu, 28 May 2009 15:29:22 -0700 (PDT) Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <4A1F0222.6030801@bangor.ac.uk> References: <4A1DF2BC.2000200@superliminal.com> <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> <4A1EF408.7010409@cox.net> <4A1F0222.6030801@bangor.ac.uk> Message-ID: <444397.985.qm@web59105.mail.re1.yahoo.com> This viewer won't do at all. It loads textures ridiculously fast. Quite annoying. I miss the solace of the grayness as textures loaded in an orderly single file. :P I have noticed I have one oddity. I have a tree Cel Edman made out of some type of sculpty. In this version it shows up as a black oval. Sort of like the devil's mirror floating in the air. Never saw anything like that before. It never loads. There are two of them rezzed out in front of my store. between the door and the landing ares. On Kali Isle. If anyone else sees this it might be worth a jira. Here is the slurl: http://slurl.com/secondlife/Kali%20Isle/180/129/22 You won't need to leave that landing spot. One of the tree sculpts is maybe 10 meters directly north of that spot. If anyone else can confirm the black ovals I would appreciate it. ________________________________ From: C J Owen To: Second Life Developer Mailing List Sent: Thursday, May 28, 2009 5:29:06 PM Subject: Re: [sldev] Yeah for Second Life 1.23.2 (2324) Addendum to my previous message. The map now loads ridiculously fast, an order of magnitude over non http fetch. This is *very* impressive. _______________________________________________ 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/20090528/fe101ef7/attachment.htm From gigstaggart at gmail.com Thu May 28 16:06:25 2009 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu, 28 May 2009 19:06:25 -0400 Subject: [sldev] VWR-13511 : Occasional crashes in OpenJPEG In-Reply-To: <30C92864-9073-4285-A80E-5A76F591AECA@lindenlab.com> References: <30C92864-9073-4285-A80E-5A76F591AECA@lindenlab.com> Message-ID: <4A1F18F1.1070502@gmail.com> Philippe Bossut (Merov Linden) wrote: > KDU is flat out 3 times faster to decode than OpenJPEG. The ratio is > consistent throughout the whole session. What ever came of that code contest where LL paid I think it was a US $5000 prize to some random person for OpenJPEG inprovements instead of soliciting submissions from established open source devs? -Jason From robla at lindenlab.com Thu May 28 16:07:54 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 28 May 2009 16:07:54 -0700 Subject: [sldev] Test sprint initial reactions Message-ID: <4A1F194A.9000604@lindenlab.com> Hi folks, We had our first test sprint today. Seems to have gone pretty well, with the expected level of chaos. Here's the transcript: https://wiki.secondlife.com/wiki/Open_Source_Meeting/2009-05-28 We have a lot of different reporting mechanisms that people have been trying out. The one that seemed to work the best was the format that Melinda Latynina used: https://jira.secondlife.com/browse/VWR-13748 Twisted Laws' higher level overview was also useful. If large sections truly are working, there's no sense in doing deeper reporting than that, so if you don't feel compelled to do microdocumentation, then don't. The big things to make sure you document: 1. Coverage: make it as clear as possible what tests you've run so far so that someone else coming along knows what still needs to be tackled. 2. Bugs: make sure you file separate issues when you find bugs. Anyway, great work! Those of you who weren't able to make it, please still chip in! We're closer, but we're not done yet: https://jira.secondlife.com/browse/VWR-13640 Also, there's lots of work to do on test plans and general organization. Please chip in there as well. Thanks Rob From lenglish5 at cox.net Thu May 28 16:39:42 2009 From: lenglish5 at cox.net (Lawson English) Date: Thu, 28 May 2009 16:39:42 -0700 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: References: <4A1DF2BC.2000200@superliminal.com> <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> <4A1EF408.7010409@cox.net> Message-ID: <4A1F20BE.6090205@cox.net> Philippe Bossut (Merov Linden) wrote: > Hi Lawson, > > On May 28, 2009, at 1:28 PM, Lawson English wrote: > >> There was a discussion today in one of the scripter's groups about >> accessing the map textures from LSL. Will it be/is it >> possible to use the http texture URLs directly from LSL to put the >> maps in-world? >> > > I'm not an LSL scripter but my understanding is that you cannot fetch > asset using http get in LSL (for plenty of reason including security). > As such, it's not possible to fetch map tiles from LSL. > > That being said, the map tiles organization and access methods are > publicly documented on the wiki: > https://wiki.secondlife.com/wiki/Webmap_AP > > The way to build the http string to access the map tile you want is > specifically described here: > https://wiki.secondlife.com/wiki/ > Webmap_API#Accessing_map_images_directly > > Thanks much. Will pass that back to the group. Lawson From moriz.gupte at gmail.com Thu May 28 17:03:04 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Thu, 28 May 2009 18:03:04 -0600 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <4A1F20BE.6090205@cox.net> References: <4A1DF2BC.2000200@superliminal.com> <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> <4A1EF408.7010409@cox.net> <4A1F20BE.6090205@cox.net> Message-ID: Hello, Just got a chance to test really quickly...spent less than 15 mins sharing info that may be useful. ATI Mobility Radeon X1600 (on Centrino Duo, 3 Gig RAM) Textures load perceptibly faster yes but there were instances where I would see large black squares on the map periodically as I zoom in and out. Changing terrain detail from low to high..also caused textures not to render properly...distorted. R On Thu, May 28, 2009 at 5:39 PM, Lawson English wrote: > Philippe Bossut (Merov Linden) wrote: > > Hi Lawson, > > > > On May 28, 2009, at 1:28 PM, Lawson English wrote: > > > >> There was a discussion today in one of the scripter's groups about > >> accessing the map textures from LSL. Will it be/is it > >> possible to use the http texture URLs directly from LSL to put the > >> maps in-world? > >> > > > > I'm not an LSL scripter but my understanding is that you cannot fetch > > asset using http get in LSL (for plenty of reason including security). > > As such, it's not possible to fetch map tiles from LSL. > > > > That being said, the map tiles organization and access methods are > > publicly documented on the wiki: > > https://wiki.secondlife.com/wiki/Webmap_AP > > > > The way to build the http string to access the map tile you want is > > specifically described here: > > https://wiki.secondlife.com/wiki/ > > Webmap_API#Accessing_map_images_directly > > > > > > > Thanks much. Will pass that back to the group. > > > 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 > -- Rameshsharma Ramloll PhD Research Assistant Professor Idaho State University, PocatelloTel: 208-282-5333 More info at http://tr.im/RRamloll -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090528/f86dbffd/attachment.htm From snowfox102 at dragonkeepcreations.com Thu May 28 17:15:17 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Thu, 28 May 2009 19:15:17 -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> Message-ID: <4A1F2915.9000004@dragonkeepcreations.com> I've tried several things recommended to me, and still I'm getting errors. Most of the time the build fails. After recompiling boost to work with Express 2008, and correcting the link dependencies to look for the right file name, I've traded one error for another. Now I get: 1>RelWithDebInfo\secondlife-bin.exe : fatal error LNK1169: one or more multiply defined symbols found Any ideas? Maya From danteferret at gmail.com Thu May 28 18:09:53 2009 From: danteferret at gmail.com (Dante Tucker) Date: Thu, 28 May 2009 21:09:53 -0400 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <4A1F2915.9000004@dragonkeepcreations.com> References: <4A1B5E64.3030502@dragonkeepcreations.com> <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> <4A1CC449.80101@dragonkeepcreations.com> <4A1F2915.9000004@dragonkeepcreations.com> Message-ID: <4d211a610905281809i23924c88o64a9aa17c2bd6e39@mail.gmail.com> I just want to throw out here that I find it hilarious that ever since the so called (I can barely say it..) "Easy build" system, not a single person I know has been able to build the viewer based on the wiki's instructions. Myself included. If you ask me it was a lot easier to build the viewer before you made it easy... if that makes any sense. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090528/ece0579a/attachment.htm From open at autistici.org Thu May 28 19:26:37 2009 From: open at autistici.org (Opensource Obscure) Date: Fri, 29 May 2009 02:26:37 +0000 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <444397.985.qm@web59105.mail.re1.yahoo.com> References: <4A1DF2BC.2000200@superliminal.com> <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> <4A1EF408.7010409@cox.net> <4A1F0222.6030801@bangor.ac.uk> <444397.985.qm@web59105.mail.re1.yahoo.com> Message-ID: <34a23a629e9b708944b30c98f5b4a5d0@localhost> On Thu, 28 May 2009 15:29:22 -0700 (PDT), Ann Otoole wrote: > I have noticed I have one oddity. I have a tree Cel Edman made out of some > type of sculpty. In this version it shows up as a black oval that prim loaded a bit slower than other sculpted prims in the same place, but I could see it correctly after a few seconds (<10). Linux Snowglobe 1.23.2 (2329) This release is working quite well - I only had some glitches with avatar textures (both skin and clothes) that I couldn't reproduce. Opensource Obscure From andromedaquonset at gmail.com Thu May 28 20:04:56 2009 From: andromedaquonset at gmail.com (Andromeda Quonset) Date: Thu, 28 May 2009 21:04:56 -0600 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <4d211a610905281809i23924c88o64a9aa17c2bd6e39@mail.gmail.co m> References: <4A1B5E64.3030502@dragonkeepcreations.com> <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> <4A1CC449.80101@dragonkeepcreations.com> <4A1F2915.9000004@dragonkeepcreations.com> <4d211a610905281809i23924c88o64a9aa17c2bd6e39@mail.gmail.com> Message-ID: <4a1f5057.1e068e0a.01f5.5bdb@mx.google.com> Interesting. I gave up trying to compile the viewer under the old system, following the specific instructions in the wiki, and asking questions here. I took the new build system with a cup of salt, and gave up on it. If it wasn't for LL and a few 3rd parties building clients, I would say the viewer can't be built. At 07:09 PM 5/28/2009, you wrote: >I just want to throw out here that I find it hilarious that ever >since the so called (I can barely say it..) "Easy build" system, not >a single person I know has been able to build the viewer based on >the wiki's instructions. Myself included. If you ask me it was a lot >easier to build the viewer before you made it easy... if that makes any sense. From merov at lindenlab.com Thu May 28 22:08:44 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 28 May 2009 22:08:44 -0700 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <4A1F0222.6030801@bangor.ac.uk> References: <4A1DF2BC.2000200@superliminal.com> <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> <4A1EF408.7010409@cox.net> <4A1F0222.6030801@bangor.ac.uk> Message-ID: <9296C235-AD26-4BDF-9ED9-445271A2BB0A@lindenlab.com> Hi all, On May 28, 2009, at 2:29 PM, C J Owen wrote: > The map now loads ridiculously fast, an order of magnitude over non > http > fetch. This is *very* impressive. Thanks CJ. Note however that most of the speed improvement (when zooming in and out) has nothing to do with http fetching but with the fact that we're now using the whole set of subresolution tiles stored on amazon S3 server. The previous (or currently existing viewer map) loads one tile *per region* regardless of the zoom level you're in. So, potentially, when zooming out really far, that maps loads on tile per region for the entire grid and subsample that to display the map. The new code loads the low resolution tiles and never fetches more pixels than needed to display on screen. A substantial saving... The consequence is a zooming speed equivalent to the SLURL Google map. The http fetch speed should show up only when zoomed in to the max. It's faster than the old map also (smaller tiles to start with since jpg images in that case are smaller than j2c + the fact we're not hitting the big LL asset server but the amazon S3) but not by an order of magnitude. Cheers, - Merov From merov at lindenlab.com Thu May 28 22:24:19 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 28 May 2009 22:24:19 -0700 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <34a23a629e9b708944b30c98f5b4a5d0@localhost> References: <4A1DF2BC.2000200@superliminal.com> <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> <4A1EF408.7010409@cox.net> <4A1F0222.6030801@bangor.ac.uk> <444397.985.qm@web59105.mail.re1.yahoo.com> <34a23a629e9b708944b30c98f5b4a5d0@localhost> Message-ID: <58387D32-F026-4175-82B4-D792DDA10A99@lindenlab.com> Hi, On May 28, 2009, at 7:26 PM, Opensource Obscure wrote: > On Thu, 28 May 2009 15:29:22 -0700 (PDT), Ann Otoole > wrote: >> I have noticed I have one oddity. I have a tree Cel Edman made out of > some >> type of sculpty. In this version it shows up as a black oval > > that prim loaded a bit slower than other sculpted prims in the same > place, > but I could see it correctly after a few seconds (<10). I wasn't as lucky and these sculpties never updated for me. Hmmm... Something to drill further. Cheers, - Merov From marinekelley at gmail.com Fri May 29 00:05:53 2009 From: marinekelley at gmail.com (Marine Kelley) Date: Fri, 29 May 2009 09:05:53 +0200 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <9e52a8c10905290000g75bb3ef6oc95cbc5dfc0f8bda@mail.gmail.com> References: <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> <4A1EF408.7010409@cox.net> <4A1F0222.6030801@bangor.ac.uk> <444397.985.qm@web59105.mail.re1.yahoo.com> <34a23a629e9b708944b30c98f5b4a5d0@localhost> <58387D32-F026-4175-82B4-D792DDA10A99@lindenlab.com> <9e52a8c10905290000g75bb3ef6oc95cbc5dfc0f8bda@mail.gmail.com> Message-ID: <9e52a8c10905290005p5f40ddcaod3bdb8ba21189241@mail.gmail.com> Arrr gmail... Sorry Merov I answered to you only. Take 2 : hi all... Note wanting to be a party pooper but... for me textures frequently fall back to grey after looking away for, say, ten minutes (and not downloading more than what a regular, static sim has to offer). This is on a MacBook pro with a decent connection and 1GB cache. It isn't doing that on 1.22.11. Same for sculpties which fall back to ovoids. Also I noticed a strange problem with the visibility of prims : when I call a llSetLinkAlpha to make a prim invisible (or simply llSetAlpha for that matter) the prim stays visible until I put my camera close, looking at it. This is systematic. Once again on a mac, I can't test it now on windows. But my biggest pet peeve is the avatar pie menu : why oh why did LL choose to move Detach to the left and placed Appearance instead ? The result is people frequently going to appearance mode when trying to detach something... This annoying to no end. I don't remember the jira entry about this but I know I am not the only one bothered by this. On the plus side, yes download times are faster, and applying changes to the preferences or moving the window no longer makes the viewer freeze on my mac (it didn't do that on windows). No crash, no disconnection, bulk permissions change is a very welcome addition as well. Can't wait to see the dynamic shadows :) Cheers Marine From open at autistici.org Fri May 29 03:53:07 2009 From: open at autistici.org (Opensource Obscure) Date: Fri, 29 May 2009 10:53:07 +0000 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <9e52a8c10905290005p5f40ddcaod3bdb8ba21189241@mail.gmail.com> References: <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> <4A1EF408.7010409@cox.net> <4A1F0222.6030801@bangor.ac.uk> <444397.985.qm@web59105.mail.re1.yahoo.com> <34a23a629e9b708944b30c98f5b4a5d0@localhost> <58387D32-F026-4175-82B4-D792DDA10A99@lindenlab.com> <9e52a8c10905290000g75bb3ef6oc95cbc5dfc0f8bda@mail.gmail.com> <9e52a8c10905290005p5f40ddcaod3bdb8ba21189241@mail.gmail.com> Message-ID: <12a695864d27ac7c9f8bd90a337dcd03@localhost> On Fri, 29 May 2009 09:05:53 +0200, Marine Kelley wrote: > Arrr gmail... Sorry Merov I answered to you only. Take 2 : > > hi all... Note wanting to be a party pooper but... for me textures > frequently fall back to grey after looking away for, say, ten minutes > (and not downloading more than what a regular, static sim has to > offer). This is on a MacBook pro with a decent connection and 1GB > cache. It isn't doing that on 1.22.11. Same for sculpties which fall > back to ovoids. I think this is currently the expected behaviour, as http://jira.secondlife.com/browse/VWR-11420 has temporarily been fixed with a change that makes textures stay around unless they've been out of view for around 9 minutes (instead of the previous 50 seconds). Viewers from 1.24 onwards have all of this code rewritten again. (this is basically Tofu's comment at VWR-11420) HTH - ciao Opensource Obscure From carlo at alinoe.com Fri May 29 03:57:43 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 29 May 2009 12:57:43 +0200 Subject: [sldev] VWR-13511 : Occasional crashes in OpenJPEG In-Reply-To: <4A1F18F1.1070502@gmail.com> References: <30C92864-9073-4285-A80E-5A76F591AECA@lindenlab.com> <4A1F18F1.1070502@gmail.com> Message-ID: <20090529105743.GA23852@alinoe.com> On Thu, May 28, 2009 at 07:06:25PM -0400, Jason Giglio wrote: > What ever came of that code contest where LL paid I think it was a US > $5000 prize to some random person for OpenJPEG inprovements instead of > soliciting submissions from established open source devs? I hope they never paid, cause something like that could easily kill the development. -- Carlo Wood From carlo at alinoe.com Fri May 29 04:18:01 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 29 May 2009 13:18:01 +0200 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <4a1f5057.1e068e0a.01f5.5bdb@mx.google.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> Message-ID: <20090529111801.GB23852@alinoe.com> On Thu, May 28, 2009 at 09:04:56PM -0600, Andromeda Quonset wrote: > Interesting. I gave up trying to compile the viewer under the old > system, following the specific instructions in the wiki, and asking > questions here. I took the new build system with a cup of salt, and > gave up on it. If it wasn't for LL and a few 3rd parties building > clients, I would say the viewer can't be built. 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: subversion [dragging in: ca-certificates libapr1 libaprutil1 libexpat1 libgssapi-krb5-2 libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 libneon27-gnutls libserf-0-0 libsvn1 libxml2 make openssl perl perl-modules sgml-base xml-core] To run configure: cmake pkg-config bison flex python [dragging in: binutils cmake-data cpp cpp-4.3 emacsen-common gcc gcc-4.3 libc6-dev libcurl3 libcurl3-gnutls libglib2.0-0 libglib2.0-data libgmp3c2 libidn11 libldap-2.4-2 libmpfr1ldbl libpcre3 libssh2-1 libxmlrpc-c3 linux-libc-dev m4 shared-mime-info file libdb4.5 libicu40 libmagic1 libsqlite3-0 mime-support python-minimal python2.5 python2.5-minimal] To compile: libapr1-dev libaprutil1-dev libssl-dev libexpat1-dev libmozjs-dev libopenjpeg-dev uuid-dev libnspr4-dev libdb-dev libsdl1.2-dev libxmlrpc-epi-dev libc-ares-dev libopenal-dev libboost-dev libogg-dev libvorbis-dev libalut-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev libatk1.0-dev libcairo2-dev libgtk2.0-dev libdbus-glib-1-dev [dragging in: build-essential bzip2 check comerr-dev cpp-4.1 dbus dbus-x11 debhelper defoma dpkg-dev esound-clients esound-common fontconfig fontconfig-config g++ g++-4.1 g++-4.3 gcc-4.1 gcc-4.1-base gettext gettext-base hicolor-icon-theme html2text intltool-debian liba52-0.7.4 libaa1 libaa1-dev libalut0 libartsc0 libartsc0-dev libasound2 libasound2-dev libatk1.0-0 libatk1.0-data libaudio-dev libaudio2 libaudiofile-dev libaudiofile0 libboost-date-time-dev libboost-date-time1.34.1 libboost-doc libboost-filesystem-dev libboost-filesystem1.34.1 libboost-graph-dev libboost-graph1.34.1 libboost-iostreams-dev libboost-iostreams1.34.1 libboost-program-options-dev libboost-program-options1.34.1 libboost-python-dev libboost-python1.34.1 libboost-regex-dev libboost-regex1.34.1 libboost-serialization-dev libboost-serialization1.34.1 libboost-signals-dev libboost-signals1.34.1 libboost-test-dev libboost-test1.34.1 libboost-thread-dev libboost-thread1.34.1 libboost-wave-dev libboost-wave1.34.1 libc-ares2 libcaca-dev libcaca0 libcairo2 libcroco3 libcups2 libdatrie1 libdb4.7-dev libdbus-1-3 libdbus-1-dev libdbus-glib-1-2 libdes425-3 libdirectfb-1.2-0 libdirectfb-dev libdirectfb-extra libdrm2 libesd0 libesd0-dev libfontconfig1 libfontconfig1-dev libfontenc1 libfreetype6 libfreetype6-dev libgl1-mesa-dev libgl1-mesa-glx libglib2.0-dev libglu1-mesa libglu1-mesa-dev libgomp1 libgpm2 libgssrpc4 libgstreamer-plugins-base0.10-0 libgstreamer0.10-0 libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libice-dev libice6 libicu-dev libjasper1 libjpeg62 libjpeg62-dev libkadm5srv5 libkdb5-4 libkrb5-dev libkrb53 libldap2-dev libmail-sendmail-perl libmozjs1d libmpeg3-1 libmpeg3-dev libmysqlclient15-dev libmysqlclient15off libncurses5-dev libnspr4-0d libogg0 libopenal1 libopenjpeg2 libpango1.0-0 libpango1.0-common libpango1.0-dev libpcre3-dev libpcrecpp0 libpixman-1-0 libpixman-1-dev libpng12-0 libpng12-dev libpopt-dev libpq-dev libpq5 libpthread-stubs0 libpthread-stubs0-dev libsdl1.2debian libsdl1.2debian-alsa libslang2-dev libsm-dev libsm6 libsqlite3-dev libstdc++6-4.1-dev libstdc++6-4.3-dev libsvga1 libsvga1-dev libsys-hostname-long-perl libsysfs-dev libsysfs2 libthai-data libthai0 libtiff4 libtimedate-perl libts-0.0-0 libvorbis0a libvorbisenc2 libvorbisfile3 libx11-6 libx11-data libx11-dev libx86-1 libxau-dev libxau6 libxcb-render-util0 libxcb-render-util0-dev libxcb-render0 libxcb-render0-dev libxcb1 libxcb1-dev libxcomposite-dev libxcomposite1 libxcursor-dev libxcursor1 libxdamage-dev libxdamage1 libxdmcp-dev libxdmcp6 libxext-dev libxext6 libxfixes-dev libxfixes3 libxfont1 libxft-dev libxft2 libxi-dev libxi6 libxinerama-dev libxinerama1 libxml2-dev libxml2-utils libxmlrpc-epi0 libxrandr-dev libxrandr2 libxrender-dev libxrender1 libxt-dev libxt6 libxxf86vm1 mesa-common-dev mysql-common patch po-debconf python-dev python2.5-dev tsconf ttf-dejavu ttf-dejavu-core ttf-dejavu-extra ucf x-ttcidfont-conf x11-common x11proto-composite-dev x11proto-core-dev x11proto-damage-dev x11proto-fixes-dev x11proto-input-dev x11proto-kb-dev x11proto-randr-dev x11proto-render-dev x11proto-xext-dev x11proto-xinerama-dev xfonts-encodings xfonts-utils xtrans-dev zlib1g-dev] To compile (not in Debian Stable): libxul-dev libcurl4-cares-dev libllmozlib2-dev [dragging in: dictionaries-common hunspell-en-us libcurl3-cares libgcrypt11-dev libgnutls-dev libgpg-error-dev libhunspell-1.2-0 libidl0 libidn11-dev libllmozlib2 libmozjs0d libnss3-1d libnss3-dev libtasn1-3-dev libxul-common libxul0d xulrunner] To install and run: gconf2 gconf2-common libgconf2-4 liborbit2 ttf-kochi-mincho [dragging in: psmisc ttf-sazanami-mincho] -- Carlo Wood From marinekelley at gmail.com Fri May 29 04:33:46 2009 From: marinekelley at gmail.com (Marine Kelley) Date: Fri, 29 May 2009 13:33:46 +0200 Subject: [sldev] Re : Yeah for Second Life 1.23.2 (2324) In-Reply-To: <12a695864d27ac7c9f8bd90a337dcd03@localhost> References: <4A1EF408.7010409@cox.net> <4A1F0222.6030801@bangor.ac.uk> <444397.985.qm@web59105.mail.re1.yahoo.com> <34a23a629e9b708944b30c98f5b4a5d0@localhost> <58387D32-F026-4175-82B4-D792DDA10A99@lindenlab.com> <9e52a8c10905290000g75bb3ef6oc95cbc5dfc0f8bda@mail.gmail.com> <9e52a8c10905290005p5f40ddcaod3bdb8ba21189241@mail.gmail.com> <12a695864d27ac7c9f8bd90a337dcd03@localhost> Message-ID: <9e52a8c10905290433k34856aa6p93e9728b58100f3f@mail.gmail.com> Thanks Mr. Opensource, this is exactly what I meant. Glad to see this is looked into ! Marine 2009/5/29, Opensource Obscure : > > On Fri, 29 May 2009 09:05:53 +0200, Marine Kelley > wrote: >> Arrr gmail... Sorry Merov I answered to you only. Take 2 : >> >> hi all... Note wanting to be a party pooper but... for me textures >> frequently fall back to grey after looking away for, say, ten minutes >> (and not downloading more than what a regular, static sim has to >> offer). This is on a MacBook pro with a decent connection and 1GB >> cache. It isn't doing that on 1.22.11. Same for sculpties which fall >> back to ovoids. > > I think this is currently the expected behaviour, as > http://jira.secondlife.com/browse/VWR-11420 has temporarily been > fixed with a change that makes textures stay around unless > they've been out of view for around 9 minutes (instead of > the previous 50 seconds). > Viewers from 1.24 onwards have all of this code rewritten again. > (this is basically Tofu's comment at VWR-11420) > > HTH - ciao > Opensource Obscure > From open at autistici.org Fri May 29 05:18:12 2009 From: open at autistici.org (Opensource Obscure) Date: Fri, 29 May 2009 12:18:12 +0000 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <58387D32-F026-4175-82B4-D792DDA10A99@lindenlab.com> References: <4A1DF2BC.2000200@superliminal.com> <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> <4A1EF408.7010409@cox.net> <4A1F0222.6030801@bangor.ac.uk> <444397.985.qm@web59105.mail.re1.yahoo.com> <34a23a629e9b708944b30c98f5b4a5d0@localhost> <58387D32-F026-4175-82B4-D792DDA10A99@lindenlab.com> Message-ID: <13cf059062dcd8620af3bc9dcbafa8c6@localhost> On Thu, 28 May 2009 22:24:19 -0700, "Philippe Bossut (Merov Linden)" wrote: > Hi, > > On May 28, 2009, at 7:26 PM, Opensource Obscure wrote: >> On Thu, 28 May 2009 15:29:22 -0700 (PDT), Ann Otoole >> wrote: >>> I have noticed I have one oddity. I have a tree Cel Edman made out of >> some >>> type of sculpty. In this version it shows up as a black oval >> >> that prim loaded a bit slower than other sculpted prims in the same >> place, >> but I could see it correctly after a few seconds (<10). > > I wasn't as lucky and these sculpties never updated for me. Hmmm... > Something to drill further. I tried again today 15-20 times and I had mixed results. It appears to me that the tree sculpted prim never loads, when you login after clearing cached. But then, if you log out and relog in, without clearing cache, it loads - slowly but in a reasonable time; it also loads if you teleport away and come back. However, I had mixed results with the leaves prim, that often didn't rez at all. During one of these tests the viewer froze. After 1 minute of total freezing I had to kill the process [*]. When I relogged I experienced http://jira.secondlife.com/browse/VWR-8215 ("Linux & Windows: After login, sometimes Mouse steering on avatar and HUDs don't work"). VWR-8215 happened also in a couple of following sessions. [*] If I rememeber correctly, the crash logger didn't worked here. Later I logged in again, and my avatar looked OK. I then switched to other applications - after some minutes I got back to SL and I got http://jira.secondlife.com/browse/VWR-3282 ("Clothing texture being replaced by a capture of my screen") ciao Opensource Obscure From snowfox102 at dragonkeepcreations.com Fri May 29 09:00:06 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Fri, 29 May 2009 11:00:06 -0500 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <20090529111801.GB23852@alinoe.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> Message-ID: <4A200686.2020906@dragonkeepcreations.com> 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: > > subversion [dragging in: ca-certificates libapr1 libaprutil1 libexpat1 > libgssapi-krb5-2 libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 > libneon27-gnutls libserf-0-0 libsvn1 libxml2 make openssl perl perl-modules > sgml-base xml-core] > > To run configure: > > cmake pkg-config bison flex python [dragging in: binutils cmake-data cpp cpp-4.3 > emacsen-common gcc gcc-4.3 libc6-dev libcurl3 libcurl3-gnutls libglib2.0-0 > libglib2.0-data libgmp3c2 libidn11 libldap-2.4-2 libmpfr1ldbl libpcre3 libssh2-1 > libxmlrpc-c3 linux-libc-dev m4 shared-mime-info file libdb4.5 libicu40 libmagic1 > libsqlite3-0 mime-support python-minimal python2.5 python2.5-minimal] > > To compile: > > libapr1-dev libaprutil1-dev libssl-dev libexpat1-dev libmozjs-dev libopenjpeg-dev > uuid-dev libnspr4-dev libdb-dev libsdl1.2-dev libxmlrpc-epi-dev libc-ares-dev > libopenal-dev libboost-dev libogg-dev libvorbis-dev libalut-dev libgstreamer0.10-dev > libgstreamer-plugins-base0.10-dev libatk1.0-dev libcairo2-dev libgtk2.0-dev > libdbus-glib-1-dev [dragging in: build-essential bzip2 check comerr-dev cpp-4.1 > dbus dbus-x11 debhelper defoma dpkg-dev esound-clients esound-common fontconfig > fontconfig-config g++ g++-4.1 g++-4.3 gcc-4.1 gcc-4.1-base gettext gettext-base > hicolor-icon-theme html2text intltool-debian liba52-0.7.4 libaa1 libaa1-dev > libalut0 libartsc0 libartsc0-dev libasound2 libasound2-dev libatk1.0-0 > libatk1.0-data libaudio-dev libaudio2 libaudiofile-dev libaudiofile0 > libboost-date-time-dev libboost-date-time1.34.1 libboost-doc > libboost-filesystem-dev libboost-filesystem1.34.1 libboost-graph-dev > libboost-graph1.34.1 libboost-iostreams-dev libboost-iostreams1.34.1 > libboost-program-options-dev libboost-program-options1.34.1 libboost-python-dev > libboost-python1.34.1 libboost-regex-dev libboost-regex1.34.1 > libboost-serialization-dev libboost-serialization1.34.1 libboost-signals-dev > libboost-signals1.34.1 libboost-test-dev libboost-test1.34.1 > libboost-thread-dev libboost-thread1.34.1 libboost-wave-dev libboost-wave1.34.1 > libc-ares2 libcaca-dev libcaca0 libcairo2 libcroco3 libcups2 > libdatrie1 libdb4.7-dev libdbus-1-3 libdbus-1-dev libdbus-glib-1-2 > libdes425-3 libdirectfb-1.2-0 libdirectfb-dev libdirectfb-extra libdrm2 > libesd0 libesd0-dev libfontconfig1 libfontconfig1-dev libfontenc1 libfreetype6 > libfreetype6-dev libgl1-mesa-dev libgl1-mesa-glx libglib2.0-dev libglu1-mesa > libglu1-mesa-dev libgomp1 libgpm2 libgssrpc4 libgstreamer-plugins-base0.10-0 > libgstreamer0.10-0 libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libice-dev > libice6 libicu-dev libjasper1 libjpeg62 libjpeg62-dev libkadm5srv5 libkdb5-4 > libkrb5-dev libkrb53 libldap2-dev libmail-sendmail-perl libmozjs1d libmpeg3-1 > libmpeg3-dev libmysqlclient15-dev libmysqlclient15off libncurses5-dev > libnspr4-0d libogg0 libopenal1 libopenjpeg2 libpango1.0-0 libpango1.0-common > libpango1.0-dev libpcre3-dev libpcrecpp0 libpixman-1-0 libpixman-1-dev > libpng12-0 libpng12-dev libpopt-dev libpq-dev libpq5 libpthread-stubs0 > libpthread-stubs0-dev libsdl1.2debian libsdl1.2debian-alsa libslang2-dev > libsm-dev libsm6 libsqlite3-dev libstdc++6-4.1-dev libstdc++6-4.3-dev > libsvga1 libsvga1-dev libsys-hostname-long-perl libsysfs-dev libsysfs2 > libthai-data libthai0 libtiff4 libtimedate-perl libts-0.0-0 libvorbis0a > libvorbisenc2 libvorbisfile3 libx11-6 libx11-data libx11-dev libx86-1 > libxau-dev libxau6 libxcb-render-util0 libxcb-render-util0-dev libxcb-render0 > libxcb-render0-dev libxcb1 libxcb1-dev libxcomposite-dev libxcomposite1 > libxcursor-dev libxcursor1 libxdamage-dev libxdamage1 libxdmcp-dev libxdmcp6 > libxext-dev libxext6 libxfixes-dev libxfixes3 libxfont1 libxft-dev libxft2 > libxi-dev libxi6 libxinerama-dev libxinerama1 libxml2-dev libxml2-utils > libxmlrpc-epi0 libxrandr-dev libxrandr2 libxrender-dev libxrender1 > libxt-dev libxt6 libxxf86vm1 mesa-common-dev mysql-common patch po-debconf > python-dev python2.5-dev tsconf ttf-dejavu ttf-dejavu-core ttf-dejavu-extra > ucf x-ttcidfont-conf x11-common x11proto-composite-dev x11proto-core-dev > x11proto-damage-dev x11proto-fixes-dev x11proto-input-dev x11proto-kb-dev > x11proto-randr-dev x11proto-render-dev x11proto-xext-dev x11proto-xinerama-dev > xfonts-encodings xfonts-utils xtrans-dev zlib1g-dev] > > To compile (not in Debian Stable): > > libxul-dev libcurl4-cares-dev libllmozlib2-dev [dragging in: dictionaries-common > hunspell-en-us libcurl3-cares libgcrypt11-dev libgnutls-dev libgpg-error-dev > libhunspell-1.2-0 libidl0 libidn11-dev libllmozlib2 libmozjs0d libnss3-1d > libnss3-dev libtasn1-3-dev libxul-common libxul0d xulrunner] > > To install and run: > > gconf2 gconf2-common libgconf2-4 liborbit2 ttf-kochi-mincho [dragging in: > psmisc ttf-sazanami-mincho] > > > From robla at lindenlab.com Fri May 29 09:35:24 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 29 May 2009 09:35:24 -0700 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <4A1F2915.9000004@dragonkeepcreations.com> References: <4A1B5E64.3030502@dragonkeepcreations.com> <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> <4A1CC449.80101@dragonkeepcreations.com> <4A1F2915.9000004@dragonkeepcreations.com> Message-ID: <4A200ECC.2040702@lindenlab.com> On 05/28/2009 05:15 PM, Maya Remblai wrote: > I've tried several things recommended to me, and still I'm getting > errors. Most of the time the build fails. After recompiling boost to > work with Express 2008, and correcting the link dependencies to look for > the right file name, I've traded one error for another. Now I get: > > 1>RelWithDebInfo\secondlife-bin.exe : fatal error LNK1169: one or more > multiply defined symbols found > > Any ideas? > Hi Maya, I'm not sure what's going on, and I'm sorry to see you're having so many problems getting the viewer built. A couple questions to start: 1. Which branch (or zipfile) of the viewer are you trying to build? 2. Can you post a few more lines of context for that build error? Rob From melinda at superliminal.com Fri May 29 11:56:51 2009 From: melinda at superliminal.com (Melinda Green) Date: Fri, 29 May 2009 11:56:51 -0700 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <9e52a8c10905290005p5f40ddcaod3bdb8ba21189241@mail.gmail.com> References: <920d7d850905281230w1c5afd39g2ced95af70e03414@mail.gmail.com> <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> <4A1EF408.7010409@cox.net> <4A1F0222.6030801@bangor.ac.uk> <444397.985.qm@web59105.mail.re1.yahoo.com> <34a23a629e9b708944b30c98f5b4a5d0@localhost> <58387D32-F026-4175-82B4-D792DDA10A99@lindenlab.com> <9e52a8c10905290000g75bb3ef6oc95cbc5dfc0f8bda@mail.gmail.com> <9e52a8c10905290005p5f40ddcaod3bdb8ba21189241@mail.gmail.com> Message-ID: <4A202FF3.6090102@superliminal.com> Marine Kelley wrote: > [...] > > But my biggest pet peeve is the avatar pie menu : why oh why did LL > choose to move Detach to the left and placed Appearance instead ? The > result is people frequently going to appearance mode when trying to > detach something... This annoying to no end. I don't remember the jira > entry about this but I know I am not the only one bothered by this. > I think you mean VWR-8080 . > On the plus side, yes download times are faster, and applying changes > to the preferences or moving the window no longer makes the viewer > freeze on my mac (it didn't do that on windows). No crash, no > disconnection, bulk permissions change is a very welcome addition as > well. Can't wait to see the dynamic shadows :) I was the one who did the bulk permissions feature as well as default upload perms feature, so I'm glad to hear that you appreciate that. Oh, and I'm also very much looking forward to dynamic shadows too. Now if only someone would do the damn SpeedTree integration already, I'd be in heaven! :-) -Melinda -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090529/45bfa03f/attachment.htm From colin.kern at gmail.com Fri May 29 12:06:46 2009 From: colin.kern at gmail.com (Colin Kern) Date: Fri, 29 May 2009 15:06:46 -0400 Subject: [sldev] Yeah for Second Life 1.23.2 (2324) In-Reply-To: <9e52a8c10905290005p5f40ddcaod3bdb8ba21189241@mail.gmail.com> References: <91EC53DC-8D1D-4405-8797-60ACA1AA877A@lindenlab.com> <4A1EF408.7010409@cox.net> <4A1F0222.6030801@bangor.ac.uk> <444397.985.qm@web59105.mail.re1.yahoo.com> <34a23a629e9b708944b30c98f5b4a5d0@localhost> <58387D32-F026-4175-82B4-D792DDA10A99@lindenlab.com> <9e52a8c10905290000g75bb3ef6oc95cbc5dfc0f8bda@mail.gmail.com> <9e52a8c10905290005p5f40ddcaod3bdb8ba21189241@mail.gmail.com> Message-ID: <77c421f00905291206o587d34e3p7deba819f7fc5c7f@mail.gmail.com> On Fri, May 29, 2009 at 3:05 AM, Marine Kelley wrote: > Also I noticed a strange problem with the visibility of prims : when I > call a llSetLinkAlpha to make a prim invisible (or simply llSetAlpha > for that matter) the prim stays visible until I put my camera close, > looking at it. This is systematic. Once again on a mac, I can't test > it now on windows. This also happens in the current 1.23 RC viewer, so it's not a problem specific to http-texture: http://jira.secondlife.com/browse/VWR-12987 Colin From jhurliman at jhurliman.org Fri May 29 15:08:31 2009 From: jhurliman at jhurliman.org (John Hurliman) Date: Fri, 29 May 2009 15:08:31 -0700 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A17340C.4020202@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> Message-ID: UDP is a poor choice for creating pipes between applications. I don't know how OSX behaves, but the networking stack in the flavors of Linux I'm familiar with and all versions of Windows are designed to drop UDP packets; even on the loopback connection. When you hit a certain frequency of message delivery (which is easy to do on loopback) you will start consistently dropping some percentage of the data. Even if you design your protocol around accepting random data loss, the deterministic way that packets are dropped will almost always lead to unacceptable results. As a side note, there is a growing body of evidence that suggests TCP will outperform UDP even in cases where UDP would be the logical choice. Decades of testing and tuning, careful synchronization of implementations (see RFC 1122 and 2988 for example), hardware acceleration of the TCP/IP stack, and a prioritization of TCP over UDP in today's routing hardware gives it a seriously unfair advantage. This isn't really related to the choice of protocol for creating a local pipe though. John On Fri, May 22, 2009 at 4:23 PM, Philip Rosedale wrote: > Looks like DBus is TCP based - that still seems unneeded, I think we > should use UDP, what think? > > Jan Ciger wrote: > > XML is definitely an overkill and certainly shouldn't be used for > > anything that has aspirations to be lightweight. > > > > Just use DBus - that is pretty standard and portable lightweight RPC > > mechanism and it is in the viewer already - it is used for passing > > slurls to the viewer from Linux browser. > > > > That would also allow easy scripting of the viewer in the future. > > > > Regards, > > > > Jan > > > _______________________________________________ > 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/20090529/6f95e7c2/attachment.htm From tom at streamsense.net Fri May 29 15:15:32 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Fri, 29 May 2009 23:15:32 +0100 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: 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> Message-ID: <4A205E84.6070507@streamsense.net> I agree. UDP was a arguably bad choice for second life in the first place, with the exception of for the object / avatar update messages. TCP for RPC.. definately :) ~Tom John Hurliman wrote: > UDP is a poor choice for creating pipes between applications. I don't > know how OSX behaves, but the networking stack in the flavors of Linux > I'm familiar with and all versions of Windows are designed to drop UDP > packets; even on the loopback connection. When you hit a certain > frequency of message delivery (which is easy to do on loopback) you > will start consistently dropping some percentage of the data. Even if > you design your protocol around accepting random data loss, the > deterministic way that packets are dropped will almost always lead to > unacceptable results. > > As a side note, there is a growing body of evidence that suggests TCP > will outperform UDP even in cases where UDP would be the logical > choice. Decades of testing and tuning, careful synchronization of > implementations (see RFC 1122 and 2988 for example), hardware > acceleration of the TCP/IP stack, and a prioritization of TCP over UDP > in today's routing hardware gives it a seriously unfair advantage. > This isn't really related to the choice of protocol for creating a > local pipe though. > > John > > On Fri, May 22, 2009 at 4:23 PM, Philip Rosedale > wrote: > > Looks like DBus is TCP based - that still seems unneeded, I think we > should use UDP, what think? > > Jan Ciger wrote: > > XML is definitely an overkill and certainly shouldn't be used for > > anything that has aspirations to be lightweight. > > > > Just use DBus - that is pretty standard and portable lightweight RPC > > mechanism and it is in the viewer already - it is used for passing > > slurls to the viewer from Linux browser. > > > > That would also allow easy scripting of the viewer in the future. > > > > Regards, > > > > Jan > > > _______________________________________________ > 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 jhurliman at jhurliman.org Fri May 29 15:18:05 2009 From: jhurliman at jhurliman.org (John Hurliman) Date: Fri, 29 May 2009 15:18:05 -0700 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: 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> Message-ID: My personal recommendation would be JSON (could even be LLSD structures serialized to JSON) over a TCP pipe. All of the infrastructure is already there in the viewer. John On Fri, May 29, 2009 at 3:08 PM, John Hurliman wrote: > UDP is a poor choice for creating pipes between applications. I don't know > how OSX behaves, but the networking stack in the flavors of Linux I'm > familiar with and all versions of Windows are designed to drop UDP packets; > even on the loopback connection. When you hit a certain frequency of message > delivery (which is easy to do on loopback) you will start consistently > dropping some percentage of the data. Even if you design your protocol > around accepting random data loss, the deterministic way that packets are > dropped will almost always lead to unacceptable results. > > As a side note, there is a growing body of evidence that suggests TCP will > outperform UDP even in cases where UDP would be the logical choice. Decades > of testing and tuning, careful synchronization of implementations (see RFC > 1122 and 2988 for example), hardware acceleration of the TCP/IP stack, and a > prioritization of TCP over UDP in today's routing hardware gives it a > seriously unfair advantage. This isn't really related to the choice of > protocol for creating a local pipe though. > > John > > > On Fri, May 22, 2009 at 4:23 PM, Philip Rosedale wrote: > >> Looks like DBus is TCP based - that still seems unneeded, I think we >> should use UDP, what think? >> >> Jan Ciger wrote: >> > XML is definitely an overkill and certainly shouldn't be used for >> > anything that has aspirations to be lightweight. >> > >> > Just use DBus - that is pretty standard and portable lightweight RPC >> > mechanism and it is in the viewer already - it is used for passing >> > slurls to the viewer from Linux browser. >> > >> > That would also allow easy scripting of the viewer in the future. >> > >> > Regards, >> > >> > Jan >> > >> _______________________________________________ >> 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/20090529/f27c6b97/attachment.htm From philip at lindenlab.com Fri May 29 15:44:11 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Fri, 29 May 2009 15:44:11 -0700 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: 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> Message-ID: <4A20653B.7020805@lindenlab.com> Hmmm. We're spending more time on this in conversation than the time required to write the code, I fear. Bummer. Well, practically speaking, we've got an intern starting who is going to write some code to try to do this thing. If our team does this, we will do it as best we can and get some code submitted. We've read this thread, so thanks. I think our direction will be to use UDP. We will do what we can and show everyone when we have working code. P John Hurliman wrote: > UDP is a poor choice for creating pipes between applications. I don't > know how OSX behaves, but the networking stack in the flavors of Linux > I'm familiar with and all versions of Windows are designed to drop UDP > packets; even on the loopback connection. When you hit a certain > frequency of message delivery (which is easy to do on loopback) you > will start consistently dropping some percentage of the data. Even if > you design your protocol around accepting random data loss, the > deterministic way that packets are dropped will almost always lead to > unacceptable results. > > As a side note, there is a growing body of evidence that suggests TCP > will outperform UDP even in cases where UDP would be the logical > choice. Decades of testing and tuning, careful synchronization of > implementations (see RFC 1122 and 2988 for example), hardware > acceleration of the TCP/IP stack, and a prioritization of TCP over UDP > in today's routing hardware gives it a seriously unfair advantage. > This isn't really related to the choice of protocol for creating a > local pipe though. > > John > > On Fri, May 22, 2009 at 4:23 PM, Philip Rosedale > wrote: > > Looks like DBus is TCP based - that still seems unneeded, I think we > should use UDP, what think? > > Jan Ciger wrote: > > XML is definitely an overkill and certainly shouldn't be used for > > anything that has aspirations to be lightweight. > > > > Just use DBus - that is pretty standard and portable lightweight RPC > > mechanism and it is in the viewer already - it is used for passing > > slurls to the viewer from Linux browser. > > > > That would also allow easy scripting of the viewer in the future. > > > > Regards, > > > > Jan > > > _______________________________________________ > 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/20090529/62df23b5/attachment.htm From melinda at superliminal.com Fri May 29 16:59:00 2009 From: melinda at superliminal.com (Melinda Green) Date: Fri, 29 May 2009 16:59:00 -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: <4A2076C4.4080800@superliminal.com> I don't agree that the amount of time required to implement this is terribly important since the amount of time required to maintain any feature over it's lifetime is roughly an order of magnitude greater. We might have spent quite a bit of calendar time so far but I don't think that anybody has made a big personal time investment yet. If that's not true, I hope that they'll tell us because you did ask for volunteers to write viewer-side patches for this. Otherwise I feel pretty good that this discussion has taken place. -Melinda Philip Rosedale wrote: > Hmmm. We're spending more time on this in conversation than the time > required to write the code, I fear. Bummer. > > Well, practically speaking, we've got an intern starting who is going > to write some code to try to do this thing. If our team does this, we > will do it as best we can and get some code submitted. We've read > this thread, so thanks. I think our direction will be to use UDP. We > will do what we can and show everyone when we have working code. > > P > > > > John Hurliman wrote: >> UDP is a poor choice for creating pipes between applications. I don't >> know how OSX behaves, but the networking stack in the flavors of >> Linux I'm familiar with and all versions of Windows are designed to >> drop UDP packets; even on the loopback connection. When you hit a >> certain frequency of message delivery (which is easy to do on >> loopback) you will start consistently dropping some percentage of the >> data. Even if you design your protocol around accepting random data >> loss, the deterministic way that packets are dropped will almost >> always lead to unacceptable results. >> >> As a side note, there is a growing body of evidence that suggests TCP >> will outperform UDP even in cases where UDP would be the logical >> choice. Decades of testing and tuning, careful synchronization of >> implementations (see RFC 1122 and 2988 for example), hardware >> acceleration of the TCP/IP stack, and a prioritization of TCP over >> UDP in today's routing hardware gives it a seriously unfair >> advantage. This isn't really related to the choice of protocol for >> creating a local pipe though. >> >> John >> >> On Fri, May 22, 2009 at 4:23 PM, Philip Rosedale >> > wrote: >> >> Looks like DBus is TCP based - that still seems unneeded, I think we >> should use UDP, what think? >> >> Jan Ciger wrote: >> > XML is definitely an overkill and certainly shouldn't be used for >> > anything that has aspirations to be lightweight. >> > >> > Just use DBus - that is pretty standard and portable >> lightweight RPC >> > mechanism and it is in the viewer already - it is used for passing >> > slurls to the viewer from Linux browser. >> > >> > That would also allow easy scripting of the viewer in the future. >> > >> > Regards, >> > >> > Jan >> > >> _______________________________________________ >> 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 merov at lindenlab.com Fri May 29 18:01:30 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Fri, 29 May 2009 18:01:30 -0700 Subject: [sldev] Recurring snowglobe crash Message-ID: <5A0F50DB-125E-49D8-9CAF-20253D0A7E14@lindenlab.com> Hi Steve, I looked into the crash reporter for snowglobe and saw the following traceback 4 times (out of 12 crashers): [0] LLError::crashAndLoop [1] LLError::Log::flush [2] LLTextureFetchWorker::~LLTextureFetchWorker [3] LLTextureFetchWorker::`scalar deleting destructor' [4] LLWorkerThread::update * e:/w-sweeper/linden/indra/llcommon/llworkerthread.cpp:112 [5] LLTextureFetch::update * e:/w-sweeper/linden/indra/newview/lltexturefetch.cpp:1589 [6] LLAppViewer::cleanup * e:/w-sweeper/linden/indra/newview/llappviewer.cpp:1339 [7] LLAppViewerWin32::cleanup * e:/w-sweeper/linden/indra/newview/llappviewerwin32.cpp:363 [8] __tmainCRTStartup [9] kernel32.dll The traceback is triggered by the "LLTextureFetchWorker::~LLTextureFetchWorker: ASSERT (mDecodeHandle == 0)". Interestingly, it always happens when the destructor is called from LLAppViewerWin32::cleanup(). Also, it happens to different residents on different regions so it doesn't appear to be context specific. I logged http://jira.secondlife.com/browse/VWR-13766 to track the issue. Cheers, - Merov From steve at lindenlab.com Fri May 29 18:17:03 2009 From: steve at lindenlab.com (Steve Bennetts (Steve Linden)) Date: Fri, 29 May 2009 18:17:03 -0700 Subject: [sldev] Recurring snowglobe crash In-Reply-To: <5A0F50DB-125E-49D8-9CAF-20253D0A7E14@lindenlab.com> References: <5A0F50DB-125E-49D8-9CAF-20253D0A7E14@lindenlab.com> Message-ID: <4A20890F.8080002@lindenlab.com> 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. -Steve Philippe Bossut (Merov Linden) wrote: > Hi Steve, > > I looked into the crash reporter for snowglobe and saw the following > traceback 4 times (out of 12 crashers): > > [0] LLError::crashAndLoop > [1] LLError::Log::flush > [2] LLTextureFetchWorker::~LLTextureFetchWorker > [3] LLTextureFetchWorker::`scalar deleting destructor' > [4] LLWorkerThread::update > * e:/w-sweeper/linden/indra/llcommon/llworkerthread.cpp:112 > [5] LLTextureFetch::update > * e:/w-sweeper/linden/indra/newview/lltexturefetch.cpp:1589 > [6] LLAppViewer::cleanup > * e:/w-sweeper/linden/indra/newview/llappviewer.cpp:1339 > [7] LLAppViewerWin32::cleanup > * e:/w-sweeper/linden/indra/newview/llappviewerwin32.cpp:363 > [8] __tmainCRTStartup > [9] kernel32.dll > > > The traceback is triggered by the > "LLTextureFetchWorker::~LLTextureFetchWorker: ASSERT (mDecodeHandle == > 0)". Interestingly, it always happens when the destructor is called > from LLAppViewerWin32::cleanup(). > > Also, it happens to different residents on different regions so it > doesn't appear to be context specific. > > I logged http://jira.secondlife.com/browse/VWR-13766 to track the issue. > > Cheers, > - Merov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090529/1963fb80/attachment.pgp From secret.argent at gmail.com Sat May 30 10:26:57 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 30 May 2009 12:26:57 -0500 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: On 2009-05-29, at 17:44, Philip Rosedale wrote: > Hmmm. We're spending more time on this in conversation than the > time required to write the code, I fear. Bummer. Welcome to big program design. Seriously, for something of this scale where you're designing protocols that will need to be done right... it's typical and often necessary to spend more time on communication than coding. From merov at lindenlab.com Sat May 30 13:40:11 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Sat, 30 May 2009 13:40:11 -0700 Subject: [sldev] Recurring snowglobe crash In-Reply-To: <4A20890F.8080002@lindenlab.com> References: <5A0F50DB-125E-49D8-9CAF-20253D0A7E14@lindenlab.com> <4A20890F.8080002@lindenlab.com> Message-ID: <237828DB-4AC7-4B03-BB66-D41E9AE27EBC@lindenlab.com> 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 Thanks Steve! Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090530/1e9965e9/attachment.htm From tateru.nino at gmail.com Sat May 30 18:37:04 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun, 31 May 2009 11:37:04 +1000 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: 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: <4A21DF40.4000904@gmail.com> Argent Stonecutter wrote: > On 2009-05-29, at 17:44, Philip Rosedale wrote: > >> Hmmm. We're spending more time on this in conversation than the >> time required to write the code, I fear. Bummer. >> > > Welcome to big program design. > > Seriously, for something of this scale where you're designing > protocols that will need to be done right... it's typical and often > necessary to spend more time on communication than coding. > I'm from the DDIT school, myself. Discussion, documentation, implementation, testing. Get the first two done right (and first!) and the last two are just straightforward engineering. -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090531/add10ea5/attachment.htm From sldev at free.fr Sun May 31 09:01:16 2009 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 31 May 2009 18:01:16 +0200 Subject: [sldev] VS Express 2005 & 2003 ? Message-ID: <20090531180116.7bc68796.sldev@free.fr> Greetings, I'm trying to make Windoze builds of the viewer (v1.19, 1.22 and 1.23). Does anyone got a link to Visual Studio Express 2003 and 2005, please ? It looks like Micro$oft put down any link to them and only provides VS2008 now... Henri. From robertltux at gmail.com Sun May 31 09:21:32 2009 From: robertltux at gmail.com (Robert Martin) Date: Sun, 31 May 2009 12:21:32 -0400 Subject: [sldev] VS Express 2005 & 2003 ? In-Reply-To: <20090531180116.7bc68796.sldev@free.fr> References: <20090531180116.7bc68796.sldev@free.fr> Message-ID: On Sun, May 31, 2009 at 12:01 PM, Henri Beauchamp wrote: > Greetings, > > I'm trying to make Windoze builds of the viewer (v1.19, 1.22 and 1.23). > > Does anyone got a link to Visual Studio Express 2003 and 2005, please ? > > It looks like Micro$oft put down any link to them and only provides > VS2008 now... I don't think you can get a "legal" copy of either at the moment so you now have the fun of getting past the fun of the odd bits resulting from 2008. Could somebody please work on devoodooing the build method?? -- Robert L Martin From sldev at free.fr Sun May 31 09:45:00 2009 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 31 May 2009 18:45:00 +0200 Subject: [sldev] VS Express 2005 & 2003 ? In-Reply-To: References: <20090531180116.7bc68796.sldev@free.fr> Message-ID: <20090531184500.da43feaa.sldev@free.fr> On Sun, 31 May 2009 12:21:32 -0400, Robert Martin wrote: > On Sun, May 31, 2009 at 12:01 PM, Henri Beauchamp wrote: > > Greetings, > > > > I'm trying to make Windoze builds of the viewer (v1.19, 1.22 and 1.23). > > > > Does anyone got a link to Visual Studio Express 2003 and 2005, please ? > > > > It looks like Micro$oft put down any link to them and only provides > > VS2008 now... > > I don't think you can get a "legal" copy of either at the moment so > you now have the fun of getting past the fun of the odd bits resulting > from 2008. > Could somebody please work on devoodooing the build method?? Actually, I just found a torrent for 2005... Not sure it can compile v1.19.0.5 yet... Did anyone have a try at cross-compiling the viewer from Linux for Windoze ? Henri. From marinekelley at gmail.com Sun May 31 10:59:36 2009 From: marinekelley at gmail.com (Marine Kelley) Date: Sun, 31 May 2009 19:59:36 +0200 Subject: [sldev] VS Express 2005 & 2003 ? In-Reply-To: <20090531184500.da43feaa.sldev@free.fr> References: <20090531180116.7bc68796.sldev@free.fr> <20090531184500.da43feaa.sldev@free.fr> Message-ID: <9e52a8c10905311059g15342ffcm4de5a9f83f33ac26@mail.gmail.com> Henri ? Are you actually trying to compile on Windows ? Are you ok ? *g* 2009/5/31 Henri Beauchamp > On Sun, 31 May 2009 12:21:32 -0400, Robert Martin wrote: > > > On Sun, May 31, 2009 at 12:01 PM, Henri Beauchamp wrote: > > > Greetings, > > > > > > I'm trying to make Windoze builds of the viewer (v1.19, 1.22 and 1.23). > > > > > > Does anyone got a link to Visual Studio Express 2003 and 2005, please ? > > > > > > It looks like Micro$oft put down any link to them and only provides > > > VS2008 now... > > > > I don't think you can get a "legal" copy of either at the moment so > > you now have the fun of getting past the fun of the odd bits resulting > > from 2008. > > Could somebody please work on devoodooing the build method?? > > Actually, I just found a torrent for 2005... Not sure it can compile > v1.19.0.5 yet... > > Did anyone have a try at cross-compiling the viewer from Linux for Windoze > ? > > Henri. > _______________________________________________ > 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/20090531/8953bc73/attachment.htm From andromedaquonset at gmail.com Sun May 31 11:22:30 2009 From: andromedaquonset at gmail.com (Andromeda Quonset) Date: Sun, 31 May 2009 12:22:30 -0600 Subject: [sldev] VS Express 2005 & 2003 ? In-Reply-To: <20090531180116.7bc68796.sldev@free.fr> References: <20090531180116.7bc68796.sldev@free.fr> Message-ID: <4a22ca61.0906c00a.513f.05a6@mx.google.com> I happened to be checking www.pricewatch.com last week, and I saw some vendors listed there that claimed to have VS 2003 in-stock. Still at the full retail price, but at least it is available. I spent a few weeks, quite some time ago, trying to compile the 1.19 viewer with VS2005, and never could get it to compile, and have given up on compiling viewers as a lost cause. Andro At 10:01 AM 5/31/2009, you wrote: >Greetings, > >I'm trying to make Windoze builds of the viewer (v1.19, 1.22 and 1.23). > >Does anyone got a link to Visual Studio Express 2003 and 2005, please ? > >It looks like Micro$oft put down any link to them and only provides >VS2008 now... > >Henri. From tigrospottystripes at gmail.com Sun May 31 11:30:49 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 31 May 2009 15:30:49 -0300 Subject: [sldev] media on the clothes Message-ID: <4A22CCD9.7080509@Gmail.com> 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? If so, are there any plans on making this trick not work anymore? (I would rather if this wasn't "fixed", it has many potential uses, not to mention how amusing it is to wear Google or somthing, even if only until the next automated rebake) From boy.lane at yahoo.com Sun May 31 12:45:27 2009 From: boy.lane at yahoo.com (Boy Lane) Date: Mon, 1 Jun 2009 03:45:27 +0800 Subject: [sldev] VS Express 2005 & 2003 ? (Henri Beauchamp) References: Message-ID: <002d01c9e228$5a50e530$6500a8c0@hp> You need VS2005. It works with both 1.22 and 1.19 (with some adaptions you will figure out). Have fun. > Date: Sun, 31 May 2009 18:01:16 +0200 > From: Henri Beauchamp > Subject: [sldev] VS Express 2005 & 2003 ? > To: sldev at lists.secondlife.com > Message-ID: <20090531180116.7bc68796.sldev at free.fr> > Content-Type: text/plain; charset=US-ASCII > > Greetings, > > I'm trying to make Windoze builds of the viewer (v1.19, 1.22 and 1.23). > > Does anyone got a link to Visual Studio Express 2003 and 2005, please ? > > It looks like Micro$oft put down any link to them and only provides > VS2008 now... > > Henri. From tillie at xp2.de Sun May 31 13:09:35 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Sun, 31 May 2009 22:09:35 +0200 Subject: [sldev] VS Express 2005 & 2003 ? (Henri Beauchamp) In-Reply-To: <002d01c9e228$5a50e530$6500a8c0@hp> References: <002d01c9e228$5a50e530$6500a8c0@hp> Message-ID: <4A22E3FF.3050402@xp2.de> Boy Lane wrote: > You need VS2005. It works with both 1.22 and 1.19 (with some adaptions you > will figure out). > Have fun. I'm still stuck with my VSE 2008 installation. :-( No way to get it running with it? Tillie From robin.cornelius at gmail.com Sun May 31 15:28:32 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun, 31 May 2009 23:28:32 +0100 Subject: [sldev] VS Express 2005 & 2003 ? (Henri Beauchamp) In-Reply-To: <4A22E3FF.3050402@xp2.de> References: <002d01c9e228$5a50e530$6500a8c0@hp> <4A22E3FF.3050402@xp2.de> Message-ID: <4A230490.40109@gmail.com> Tillie Ariantho wrote: > Boy Lane wrote: > >> You need VS2005. It works with both 1.22 and 1.19 (with some adaptions you >> will figure out). >> Have fun. > > I'm still stuck with my VSE 2008 installation. :-( No way to get it running with it? It does work if you replace the pre-built boost libraries. This is becoming such a problem now (as 2005 is quite difficult to get hold of for express) i think its time we had some definitive instructions that walk people through the process of sorting out the boost libraries for VS2008. I'll try to throw an updated version of the instructions together and see if i can host some prebuilt boosts for 2008 to save some effort here. 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/20090531/7b9e02af/attachment.pgp From tillie at xp2.de Sun May 31 16:49:47 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Mon, 01 Jun 2009 01:49:47 +0200 Subject: [sldev] VS Express 2005 & 2003 ? (Henri Beauchamp) In-Reply-To: <4A230490.40109@gmail.com> References: <002d01c9e228$5a50e530$6500a8c0@hp> <4A22E3FF.3050402@xp2.de> <4A230490.40109@gmail.com> Message-ID: <4A23179B.5070200@xp2.de> Robin Cornelius wrote: > I'll try to throw an updated version of the instructions together and > see if i can host some prebuilt boosts for 2008 to save some effort here. Thanks a lot, that would be very helpful. :-) Tillie From snowfox102 at dragonkeepcreations.com Sun May 31 17:07:48 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Sun, 31 May 2009 19:07:48 -0500 Subject: [sldev] VS Express 2005 & 2003 ? (Henri Beauchamp) In-Reply-To: <4A230490.40109@gmail.com> References: <002d01c9e228$5a50e530$6500a8c0@hp> <4A22E3FF.3050402@xp2.de> <4A230490.40109@gmail.com> Message-ID: <4A231BD4.4050800@dragonkeepcreations.com> Robin Cornelius wrote: > I'll try to throw an updated version of the instructions together and > see if i can host some prebuilt boosts for 2008 to save some effort here. > > Robin > Please do, I haven't found a way to get the code to compile in 2008. On the subject of 2005, the files are still on Microsoft's website. So if you can find the installer you can still download it from Microsoft. Honestly I don't get why so many companies take their freeware off their websites. -_- Anyway I got 2005 that way, and compiled the viewer just fine. Maya From robla at lindenlab.com Sun May 31 17:31:08 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Sun, 31 May 2009 17:31:08 -0700 Subject: [sldev] Asset bundle downloader (public_fetch_tarballs.py) Message-ID: <4A23214C.7000905@lindenlab.com> Hi folks, As a little weekend coding project, I decided to write a downloader for the asset URLs listed in doc/asset_urls.txt This has been done many times before as shell scripts and such, but I wanted to write something that doesn't require Cygwin, doesn't rely on symlinks to make the "linden" thing work, and generally works similarly to install.py so that it'll drop right into our build process should we decide to integrate it. So, here's the first version (attached). I'm going to check this into the "scripts" directory after a little more testing and fiddling around. If you'd like to offer feedback on this, or just get into a bikeshed argument about the name before I check it in, please do so here: http://jira.secondlife.com/browse/VWR-13787 Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: public_fetch_tarballs.py Type: text/x-python Size: 9776 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090531/e8264bd3/attachment.py From jessesa at gmail.com Sun May 31 18:49:54 2009 From: jessesa at gmail.com (Jesse Barnett) Date: Sun, 31 May 2009 21:49:54 -0400 Subject: [sldev] VS Express 2005 & 2003 ? (Henri Beauchamp) In-Reply-To: <4A231BD4.4050800@dragonkeepcreations.com> References: <002d01c9e228$5a50e530$6500a8c0@hp> <4A22E3FF.3050402@xp2.de> <4A230490.40109@gmail.com> <4A231BD4.4050800@dragonkeepcreations.com> Message-ID: Sorry about all the emails by mistake Maya but that's what you get for making me find the link when you had it today :) http://www.softpedia.com/get/Programming/Other-Programming-Files/Microsoft-Visual-C-Toolkit.shtml That page has a link back to a Microsoft server: http://go.microsoft.com/fwlink/?LinkId=51410&clcid=0x409 Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090531/f34a6e1f/attachment.htm From jodiah at my-webhome.com Sun May 31 20:08:42 2009 From: jodiah at my-webhome.com (jodiah at my-webhome.com) Date: Sun, 31 May 2009 20:08:42 -0700 Subject: [sldev] Compiling successfully with VC++ 2008 Express Message-ID: <20090531200842.8b0823960ceb6a56f7ddf638f99b00cb.cbf02dfacf.wbe@email.secureserver.net> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090531/bd5c48b5/attachment-0001.htm From robertltux at gmail.com Sun May 31 20:46:21 2009 From: robertltux at gmail.com (Robert Martin) Date: Sun, 31 May 2009 23:46:21 -0400 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: On Sun, May 31, 2009 at 11:08 PM, wrote: > Something I didn't mention on my page, make sure you start Visual Studio > with the SecondLife.sln solution in the?..\linden\indra\build-VC90 folder > that is built when you run develop.py. There will be many other Solution > files and vcproject files, but the aforementioned solution file worked best > for me. > > I really hope some of this info?helps someone with their struggle to compile > the 1.22.11 viewer code. > > Cheers, > Jodiah and now for your next trick could you do the same with a SnowGlobe copy?? -- Robert L Martin From bogus@does.not.exist.com Tue May 12 12:06:01 2009 From: bogus@does.not.exist.com () Date: Tue, 12 May 2009 19:06:01 -0000 Subject: No subject Message-ID: 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.