[opensource-dev] What is with the cycling port connections on SLv2.4?
connect disconnect connect 4 times at once disconnect 4 bang bang hammer hammer Dear Oz and Esbee: Run a port monitor and look at what your client is doing. Please. No don't just do it from the office LAN. Hire someone to travel around to different areas of the country to monitor what your client really does. Seriously. Crashiest client ever. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] disappearing friends
I see no discrepancies in the viewer I use. What viewer(s) and versions are you using? From: Erin Mallory for some reason like 1/3 of my friends list randomly unfriended themselves including 3 of my own alts that I did not unfriend. Some people at the auction im at have said the same thing. anyone else noticing this? did LL impliment something new? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] STORM-243 - simulator version notifications
Doesn't it add some minor overhead to region crossings? I don't care about it. The message does not say what server version you just entered so it is mostly an annoyance. If I need version info I know where it is. What I would like to see is region rating and a single letter server version code on the map without having to mouse float. From: Kent Quirk (Q Linden) Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] UI - Picks - no delete button
So exactly how do I delete a pick? Oh never mind. I have to get a third party viewer to do it. Great. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] UI - Picks - no delete button
I don't see any trashcan. Expected. Looked. Not there. v2.5. No way to delete picks. From: Geenz To: Ann Otoole Cc: opensource-dev@lists.secondlife.com Sent: Wed, February 16, 2011 4:42:11 AM Subject: Re: [opensource-dev] UI - Picks - no delete button It's totally not Right click on the pick -> Delete. It's totally not click on the pick in question, then click on the trash can icon at the bottom of "My Picks". On Wednesday, February 16, 2011 at 3:39 AM, Ann Otoole wrote: So exactly how do I delete a pick? Oh never mind. I have to get a third party viewer to do it. Great. > > >___ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] STORM-9 - sharing location and status message to Twitter
How does Twitter's new restrictions on 3rd party apps factor in on this since Twitter changed things recently? From: Opensource Obscure To: OpenSource Mailing List Sent: Sun, March 20, 2011 2:43:57 PM Subject: [opensource-dev] STORM-9 - sharing location and status message to Twitter I just commented STORM-9, that is "As a User, I want to share my location and a custom status with friends on Twitter so they can follow what I’m up to in Second Life" ... ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Concerned about frequent crashes
Yes. It is so bad I was unable to be logged in for more than a minute in a sim with 40+ people last night. I installed Phoenix and had no problems rezzing all the avatars and no crashes for hours. Teleports were instant. Everything works really fast. The issues with geometry appears to reside soley with LL's SLv2. V1.x appears capable of rendering anything thrown at it. From: Marine Kelley To: Lee ponzu Cc: Opensource_dev Sent: Sunday, August 7, 2011 2:07 PM Subject: Re: [opensource-dev] Concerned about frequent crashes I crash a lot on 2.8.0, at least twice a day. It is usually a sudden crash to desktop, and from the log it looks like the viewer goes short on memory. It happens more often with deferred rendering on, but it is always random, I could never link it to any particular action I take. My computer has 4GB memory, and is running Win 7 that takes 1.5GB all by itself. But I would believe that 2GB should be enough for the SL viewer... It keeps eating more and more memory though. Seems there is a huge memory leak in the deferred renderer. On 07/08/2011, Lee ponzu wrote: > I am concerned that the latest viewers have been crashing a lot for the last > week or two. I crash as often as 3 times per hour. I attach one crash > report below. Is this problem known and being worked on, or is it just me? > I am sort of a canary in the coal mine because this is an older iMac and I > use Satellite internet, so maybe I expose problems that don't crash other > people. > > Question: When OS X pops up a Problem Report for a crashed app, and says > the report is being sent to Apple, do those actually go anywhere? Is there > any maybe automated analysis and statistics done? If not, would it be > useful? Maybe I could help there. > > ponzu > > Process: Second Life [908] > Path: /Applications/Viewers/Project Viewer - > Mesh.app/Contents/MacOS/Second Life > Identifier: com.secondlife.indra.viewer > Version: Second Life version 2.8.2.237321 (2.8.2.237321) > Code Type: X86 (Native) > Parent Process: launchd [631] > > Date/Time: 2011-08-07 13:26:05.591 -0400 > OS Version: Mac OS X 10.6.8 (10K549) > Report Version: 6 > > Interval Since Last Report: 228428 sec > Crashes Since Last Report: 4 > Per-App Interval Since Last Report: 29574 sec > Per-App Crashes Since Last Report: 3 > Anonymous UUID: 18404959-AFD8-476A-807F-8B2EE7A368F6 > > Exception Type: EXC_CRASH (SIGQUIT) > Exception Codes: 0x, 0x > Crashed Thread: 1 Dispatch queue: com.apple.libdispatch-manager > > Thread 0: Dispatch queue: com.apple.main-thread > 0 libSystem.B.dylib 0x91b75c5a __kill + 10 > 1 libSystem.B.dylib 0x91b75c4c kill$UNIX2003 + 32 > 2 libSystem.B.dylib 0x91c085a5 raise + 26 > 3 libllcommon.dylib 0x04965480 > default_unix_signal_handler(int, __siginfo*, void*) + 432 > 4 libSystem.B.dylib 0x91b7b05b _sigtramp + 43 > 5 libSystem.B.dylib 0x91b40f56 wait4 + 10 > 6 libSystem.B.dylib 0x91ba25e5 pclose + 215 > 7 libllcommon.dylib 0x04a333de LLMemoryInfo::loadStatsMap() + > 3598 > 8 libllcommon.dylib 0x04a34763 LLMemoryInfo::refresh() + 35 > 9 libllcommon.dylib 0x04a401ee FrameWatcher::tick(LLSD const&) > + 606 > 10 libllcommon.dylib 0x04a356d2 > boost::detail::function::function_obj_invoker1 boost::_mfi::mf1, > boost::_bi::list2, boost::arg<1> > >, bool, > LLSD const&>::invoke(boost::detail::function::function_buffer&, LLSD const&) > + 82 > 11 com.secondlife.indra.viewer 0x0175e689 > boost::signals2::detail::signal1_impl float, std::less, boost::function, > boost::function, > boost::signals2::mutex>::slot_invoker::m_invoke(boost::shared_ptr boost::optional >, boost::signals2::slot1 boost::function >, boost::signals2::mutex> > const&, > ...) const + 57 > 12 com.secondlife.indra.viewer 0x0175e94d > boost::signals2::detail::signal1_impl float, std::less, boost::function, > boost::function, > boost::signals2::mutex>::operator()(LLSD const&) + 525 > 13 libllcommon.dylib 0x049a71df LLEventStream::post(LLSD > const&) + 63 > 14 com.secondlife.indra.viewer 0x000de32d LLAppViewer::mainLoop() + 1453 > 15 com.secondlife.indra.viewer 0x01350918 main + 568 > 16 com.secondlife.indra.viewer 0x9ad6 start + 54 > > Thread 1 Crashed: Dispatch queue: com.apple.libdispatch-manager > 0 libSystem.B.dylib 0x91b3b382 kevent + 10 > 1 libSystem.B.dylib 0x91b3ba9c _dispatch_mgr_invoke + 215 > 2 libSystem.B.dylib 0x91b3af59 _dispatch_queue_invoke + 163 > 3 libSystem.B.dylib 0x91b3acfe _dispatch_worker_thread2 + 240 > 4 libSystem.B.dylib 0x91b3a781 _pthread_wqthread + 390 > 5 libSystem.B.dylib 0x91b3a5c6 start_wqthread + 30 > > Thread 2: > 0 l
Re: [opensource-dev] Viewer UI mode merge
>From my lengthy gaming experience what is called mini map in SL is called >radar in lots of games. Perhaps the radar like icon is a good call. IMHO From: Hitomi Tiponi To: Opensource_dev Sent: Wednesday, October 19, 2011 11:38 AM Subject: Re: [opensource-dev] Viewer UI mode merge There is a lot of really good stuff in this release including some icons that look similar to those used in Firestorm and StarLight - so especially like them :). Some are a bit odd, like the mini-map which I would use for a radar instead, but generally they are of a high quality. Were any non-techie users involved in these discussions I wonder - after all a lot of users who use SL just for socialising have very different requirements, especially with regards to chat/IMs? >For those of us that attend the in world meetings concerning the viewer it >had been know that this was coming for a couple of months and I has even had >a discussion with some of the UI team personally concerning some aspects of >the UI both in world and via email some of which even included sending a >snapshot of Firestorms UI with it in the Starlight Silver/Blue theme. So to >me this is no surprise. Now for my personal taste it look like ill have to >go in and edit some of the background png files again so that they are >semi-transparent again at least locally for me. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] GTX680 Compatibility
Will SL run on the new nVidia GTX680? If not are there any plans to advance Secondlife with the way Video card technology is moving?___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] GTX680 Compatibility
I know there are some interesting changes in respect to shaders. Also some possible disinformation going around about no shaders but that looks to be bogus. Maybe we will have to wait and see what happens to the first lucky person into the pool with a 680. From: Geenz To: Ann Otoole Cc: Viewer Sent: Friday, April 6, 2012 2:12 PM Subject: Re: [opensource-dev] GTX680 Compatibility It *should* run, provided Nvidia hasn't done anything funky with their drivers. -- Geenz Sent with Sparrow On Friday, April 6, 2012 at 1:43 PM, Ann Otoole wrote: Will SL run on the new nVidia GTX680? If not are there any plans to advance Secondlife with the way Video card technology is moving? > > >___ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Thankfully the previously bad aos are not so bad now. If a client side AO cannot perform what Oracul and/or Vista AOs do then it is a total waste of time to bother with the client side code. In order to do client side AOs requires AO expertise. Period. Don't even bother if you don't have it. Because it will be a waste and people will still use AOs. From: Lance Corrimal To: opensource-dev@lists.secondlife.com Sent: Thursday, April 12, 2012 11:56 AM Subject: Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs > * To discover use cases and what problems in-viewer AOs were created > to solve Until recently the AO hud of one particular famous AO vendor used up a whopping 4.5 MEGABYTES of script memory. FCOL i can run a MAIL SERVER in that much. bye, LC ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Third party viewer policy
I've already learned the hard way time spent in or around Second Life is a career death sentence. It doesn't matter what happens down the road. The taint is permanent. Second Life cannot be mentioned in public. Time in this business is lost years. From: Henri Beauchamp To: opensource-dev@lists.secondlife.com Sent: Thu, February 25, 2010 6:40:28 AM Subject: Re: [opensource-dev] Third party viewer policy On Thu, 25 Feb 2010 12:31:13 +0100, Lance Corrimal wrote: > Am Donnerstag, 25. Februar 2010 12:18:23 schrieb Henri Beauchamp: > > > My guess is that we will soon hear about discriminations based on > > private info gathered on Internet (Employee: "oh, why can't I get this > > job, sir ?" - Employer: "Because you use your avatar in SL to rolepay > > BDSM, you sicko !"). > > > given how MANY people are really kinky on SL I'd expect that to turn out the > other way: > > "You're hired but only if you tie me to this cross and take me from behind > you > stud you! I KNOW You like that stuff!" Lol ! I'll consider that option... ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] FAQ posted for Third Party Viewer Policy
So basically I cannot grant export for use in other grids licenses and must instead use some sort of a tool to export the assemblies myself and market them outside of SL as import packages. That seems to be problematic but more so it appears LL is attempting to deny the right to export any of your own work, licensed for intergrid use, for use elsewhere. We need the authorized viewer exports to include the texture binaries for textures and sculpties, that we uploaded ourselves, in the exports so the import packages will be complete and not dependent upon the LL asset system via UUID. And I expect the textures sold in SL intended for download and modification to be made in world use only and texture sellers will have to begin distribution of textures for derivative use outside SL. The question arises why should texture artists sell in SL or on xstreet at all at this point. LL is going to cut off revenue sources. From: Morgaine To: Soft Linden Cc: opensource-dev@lists.secondlife.com Sent: Sat, February 27, 2010 1:47:04 AM Subject: Re: [opensource-dev] FAQ posted for Third Party Viewer Policy Soft, this is quite a good FAQ (particularly compared to TPV #1:P) as it clears up a large number of points. I thought it might resolve the earlier problems re GPL compliance, particularly since it addresses the GPL directly. But when I examined it more closely it still has holes and confusion on the key points. Take FAQ.2 for example: Q2: Does the policy limit use of the viewer source code that Linden Lab makes available under the GPL? A2: No, the policy is not intended to and does not place any restriction on modification or use of our viewer source code that we make available under the GPL. Rather, the policy sets out requirements for connecting to our Second Life service using a third-party viewer, regardless of the viewer source code used. This looks great at first glance as it appears to make the separation between developers and users that caused so much confusion in TPV v1. But notice that the answer says "does not place any restriction on modification or use", and then goes on to say "Rather, the policy sets out requirements for connecting". Well connecting IS use, it couldn't be anything else, so the answer contradicts itself in one and the same paragraph. Such ambiguities need to be removed. The sentence was probably intended to say "does not place any restriction on modification or distribution", in order to clear the hurdle of GPLv2 clause 6. That clause explicitly requires freedom of modification and distribution. Nothing else will do, so if you want to be clear about GPL compliance, those words had better be there in A2. :-) Unfortunately, the question itself is confusing because it refers to use of the source code, and the GPL is completely unconcerned about use. Really the question should ask: * Q2: Does the policy limit modification and distribution of the viewer source code that Linden Lab makes available under the GPL? If that were the question then it would make sense in the context of addressing GPLv2 clause 6 directly, and it would match the corrected answer I gave above. Next, FAQ.12: * Q12: I develop for a Linux distribution where there is no opportunity to present users with the disclosures required under section 1.c before the user downloads and installs the software. How can I comply with section 1.c of the policy? * A12: For Linux distributions where there is no opportunity to provide the section 1.c disclosures before installation of the software, you can comply with the requirement by having your software client present the required disclosures or a link to them in a dialogue box that the user must close before logging into Second Life for the first time through your software. You can't require that of developers of GPL software. It's a restriction on a GPL developer's "freedom to modify and distribute", and is explicitly prohibited in GPLv2 clause 6. Please check the GPLv2 FAQ for the example of the original BSD advertising clause, which was incompatible with the GPL. That advertising clause had to be removed from GPL programs before they could be licensed using GPL, because it was an additional restriction on the freedom to modify and distribute. Your requirement is similar but much more onerous. It is a very clear additional restriction on the freedom to modify and distribute: for example, it restricts removal of the disclosure or dialogue box. Such an additional restriction is not permitted under GPL. Indeed, no additional restrictions on the freedom to modify and distribute are permitted at all. And finally, FAQ.15 (in the context of licenses permitting free distribution): * Q15: Do the limitations of section 2.b on content export apply to content that is full permissions? * A15: Yes, they do. Residents retain intellectual prope
Re: [opensource-dev] FAQ posted for Third Party Viewer Policy
OK I have read this and in plain English it is pretty clear. So I expect Linden Lab will be terminating the ability to save full permissions textures to disk unless the person saving them uploaded them right? And since Linden Lab's viewer cannot determine license state of builds in view then Linden Lab will be removing snapshot capabilities and informing residents they are not allowed to view content unless they own the region and all content in view right? No machinima nothing. After all if it can be seen it can be "illegally screenshot". Or are these restrictions only applicable to third party viewers for the purpose of rendering them useless? From: Soft Linden To: Morgaine Cc: opensource-dev@lists.secondlife.com Sent: Sat, February 27, 2010 8:31:40 PM Subject: Re: [opensource-dev] FAQ posted for Third Party Viewer Policy On Sat, Feb 27, 2010 at 12:47 AM, Morgaine wrote: > ... > And finally, FAQ.15 (in the context of licenses permitting free > distribution): > > Q15: Do the limitations of section 2.b on content export apply to content > that is full permissions? > A15: Yes, they do. Residents retain intellectual property rights in the > content they create in Second Life and it is important for you to respect > those rights. By setting content to "full permissions" using the Second > Life permissions system, a content creator merely indicates that the content > may be copied, modified, and transferred within Second Life. Setting > content to "full permissions" does not provide any permission to use the > content outside of Second Life. > > This is fine (surprise, surprise :P), but incomplete. It doesn't address > the quite common scenario of full-perm content created by Open Source or > Creative Commons developers using 100% personal textures, and accompanied by > a GPL, BSD, CC or other open source license which declares that the content > may be freely copied, modified, and transferred anywhere, not only within > Second Life. > > As is written in the answer A15, "Residents retain intellectual property > rights in the content they create in Second Life and it is important for you > to respect those rights." Respecting their rights in this case requires you > to to allow that content to be exported as its creator desires. Therefore > you either need to extend A15 with this additional case, or add another FAQ > Q+A (preferably immediately after #15) to address it. That might be material for the FAQ. But because there is no export permission bit, it's not possible to add export capability for these cases without enabling violation of others' content. At this point, I couldn't see that affecting the TPV policy. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] FAQ posted for Third Party Viewer Policy
The 5.6 is obviously LL shifting liability for "bad viewer" users to the person that wrote it. Can't blame them for that. Only problem is the "bad viewer" writers never cared and will keep right on doing what they do and the counterfeiters and shoplifters will keep right on doing what they do using throw away accounts unimpeded. So the net effect of this is nill except future lawsuits will have to be filed against the people that wrote the "bad viewers". Naturally I would love to see the "bad viewer" writers identities exposed as part of public record in legal proceedings. But I don't see it happening anytime soon. The ripping off will continue. useful backup features will be removed from good viewers. Since Joe Linden is reading and participating I must ask if LL will be correcting their viewers' non compliance by implementing creator only controls on full permissions texture save to disk or just removing the feature since the creator already has the texture on disk? Because if LL leaves it in then that constitutes export of full permissions textures regardless of creator which means full permissions exports should be allowed. Given Linden Lab is in an odd position to be making licenses for the artists like that I am curious. Which will it be? Is LL going to get into compliance with their own TOS or change the TOS? Oh and what about snapshots and machinima since there might be licensing issues if content not created by the filmer/photographer is in view? From: Bryon Ruxton To: Morgaine ; Joe Linden Cc: opensource-dev@lists.secondlife.com Sent: Sun, February 28, 2010 8:30:39 PM Subject: Re: [opensource-dev] FAQ posted for Third Party Viewer Policy Re: [opensource-dev] FAQ posted for Third Party Viewer Policy Morgaine, I think your statement is a misunderstanding on your part. It’s not “just promotion”. You don’t have a choice but to be be listed AND comply if you want to legitimately connect to the grid with your viewer. As originally intended by LL. They are not exclusive as currently implemented and described, unless they change that: “agree to our Policy on Third-Party Viewers and the Second Life Terms of Service. If you do not agree, you are ineligible for the Viewer Directory, and you do not have permission to access Second Life using a third-party viewer.“ i.e. You either comply AND feature in the "viewer registry". OR ignore it, as you said and you’d be in breach of the TOS as such: “5.6 You will indemnify Linden lab from claims arising from breach of this Agreement by you, from your use of Second Life, from loss of Content due to your actions, or from alleged infringement by you”. And I don’t think opting out of the "viewer registry" should or ever will be an option. On 2/28/10 4:44 PM, "Morgaine" wrote: Joe, thanks for clarifying that what you are doing with the Directory is "promotion" of Third Party Viewers. Since it's just promotion, TPV developers are free to ignore it when they excel on features and don't need promotion, and of course you will never make promotion mandatory. > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Script memory limit vs server CPU utilization as a key metric
Oddly it is pretty much a fact that when over 10 avatars enter my region and script time goes up far enough for spare time to remain at zero the sim starts lagging. Lagging as in rubber banding, getting pending downloads rising, etc. Not sure what sort of sims you guys are looking at but it is rather obvious to us that actually use Second Life and have to monitor this daily and then have to restart the region daily or so to get the sim under control seem to have a totally different experience than what you describe. Once upon a time we could get 100 avatars in a sim. Sure there would be lag. Lag like you now get with more than 20 in a sim. I do see the stats in the viewer go nuts from time to time. Perhaps that is related to some other sim on the same host causing the swap problem? Because it happens from time to time even when there are only a couple of avatars in the sim. Personally I think the observations made over more than a year that prove the sim lags when script time consumes so much time there is no spare time left in a frame is rather accurate. Because the lag happens every time the saturation occurs. If you guys want to really help then give us the ability to disable scripts by attachment creator name. There are certain products that cause problems. Made by people LL props up as shining examples of how creators should be BTW lmao. Sorry but it doesn't appear to me like you guys are monitoring islands with even low to medium traffic too much. Oh and are you running 8 private islands to a host now? Or is the service that tries to let you know who all is on the same region simply incorrect? Thanks for clearing that question up if possible. From: Kelly Linden To: Joel Foner Cc: opensource-dev@lists.secondlife.com Sent: Tue, March 9, 2010 3:57:13 PM Subject: Re: [opensource-dev] Script memory limit vs server CPU utilization as a key metric Hi Joel. This is an interesting issue. You would think CPU would be the big issue, but really it isn't. * We actually do a decent job of time slicing scripts. You add a lot of scripts and in general just the scripts run slower, sim performance isn't that impacted. * WAIT! Before you yell at me for that statement read this one: most of the script sources of lag are *specific* and actually caused by LSL triggered non-LSL events. For example temp-rezzers can kill sim performance. It isn't the script that kills it though, it is the rezzing of the object, and the derezzing. Yes the script causes that, but it isn't script CPU type that is hindering the performance. (BTW we are working on reducing the impact of rezzing! ssshhh) * ALL RIGHT! Yes there are other exceptions, scripts with high script time that effect the sim. But these are generally exceptions. The summary is though, that script CPU time is relatively well handled, though I admit it could be better. * Yes better allocating script CPU time so that one user can't impact the scripts of everyone else is also a great goal - it just isn't as high a priority as script memory right now. moving on * Sim's going in to swap is one of the biggest issues with sim peformance we have right now. It is significantly more of a problem than script CPU time. And when it happens all stats tank. * The fact that script memory is unbounded, that you can have a single prim object with thousands of scripts (technically unlimited, but the viewer behaves weird after a while) is a real problem. Someone built a GoogleFS-like system in SL that could in theory hold many gigabytes of data. They thankfully never deployed the full system. * When sims use too much memory they don't just affect themselves they affect their neighbors - the other regions running on the same host. So yeah, it is kind of weird, but memory is the bigger performance issue so we have chosen to address it first. - Kelly PS - nice to chat with you again, feel free to contact me directly if you wanna chat more. Hope things are going well. On Tue, Mar 9, 2010 at 10:49 AM, Joel Foner wrote: Many apologies if this has been discussed at length in a place that I've missed... > > >I'm a bit baffled by the continuing strong focus on memory utilization of >scripts rather than CPU load on the host servers. If (maybe I'm missing an >important issue here) the issue is to avoid a resident or scripted item from >causing performance problems on a region, wouldn't the relative CPU load >imposed by that script be a critical item? > > >I understand that if the total active memory size for a server goes above it's >physical available RAM, then paging would increase and potentially create >issues. Is there some objective analysis of servers with the Second Life >simulator code on to show that they go into continuous swap mode in this case, >or is it occasional "blips" of performance degradation on a slower interval? >It seems to me that having continuing excessive CP
Re: [opensource-dev] Script memory limit vs server CPU utilization as a key metric
Please do not answer my query directed to Kelly Linden unless you are Kelly Linden. From: Argent Stonecutter To: opensource-dev@lists.secondlife.com Sent: Wed, March 10, 2010 7:37:18 AM Subject: Re: [opensource-dev] Script memory limit vs server CPU utilization as a key metric On 2010-03-10, at 05:51, Ann Otoole wrote: > Oddly it is pretty much a fact that when over 10 avatars enter my > region and script time goes up far enough for spare time to remain > at zero the sim starts lagging. Lagging as in rubber banding, > getting pending downloads rising, etc. Which is caused by script memory getting so high that the sim starts swapping. Yes, that may show as high script time because the time needed to swap in the scripts again will get charged against the script. Whether the scripts are disabled or not is irrelevant, if they're still loaded. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Request for comments about llSetAgentEnvironment / SVC-5520
What would be wrong with a dialog that informs the visitor they can have an enhanced experience by accepting the environment settings that are optimal. Of course some of us would want those settings to become an available option anywhere so it is a matter of the owner providing the settings and the server sending the xml down to the client and installing them in the appropriate directories (sky, water, etc.) An example would be the Bryn Oh Immersiva region. It takes quite a bit of time to adjust the touchy and near impossible to fine tune sky settings to meet the settings that are made available by touching a kiosk. So not only do we need these settings to come down on demand automatically the windlight settings need to have value input boxes for exact settings instead of the sliders that are difficult to get to a specific setting. As for the concerns of malicious intent well there is an abuse reporting system for that. In addition glow needs to be restricted to 0 to 1. Anything over 1 can damage a video card so it should not even be allowed to overdrive like that. I learned the hard way when i literally burned up a dual SLI system experimenting with modulating glow. The ozone stench was significant. From: Kelly Linden To: Maggie Leber (sl: Maggie Darwin) Cc: opensource-dev@lists.secondlife.com Sent: Wed, March 10, 2010 12:57:50 PM Subject: Re: [opensource-dev] Request for comments about llSetAgentEnvironment / SVC-5520 On Wed, Mar 10, 2010 at 9:53 AM, Maggie Leber (sl: Maggie Darwin) wrote: > >>If it was easier to do, would you even be lobbying to make them >>automatic under the control of the parcel owner? > Absolutely. In fact, being easy to change / fix / revert would be a pre-req in my mind. > > >>> I think we get more amazing in world experiences that way. > >If I'm going to have "amazing experiences", I'd like to to be >>voluntary, thanks. And if you're going to accuse me of >>"fear-mongering" and "panic", do kindly read the JIRAs first. > They should be voluntary in the sense that any content or place in SL is voluntary. The very sky around you should be part of the content, part of the place. I can't get over how awesome I think that would be. - Kelly ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Open Viewer Development Announcement
I use SLv2 code base viewers unless I need to go into complex build environments. The SLv2 code has a lot of performance issues that don't exist in the 1.x code. And it has nothing to do with avatar attachments since the crashes occur in regions with only me in them. When I need to go to those "fabulous builds" (with ktris/fr measurements in the range of 3 million polys or more) I am forced to use snowglobe 1.4. I think there is a lot of efficiency to be gained from revisiting the menus/commands and considering a multi row user configurable hot bar for people to customize for the modes they operate in. So anyway... How about soliciting requirements from us customers and then letting us customers prioritize them and then you go through the process of explaining why you will or will not implement. Maybe there is a bastion of software methodology expertise amongst us customers and we could organize a requirements system for you. Then the OS developers can choose if they want to continue with the high demand features in a TPV for SL or just take what the customers are asking for to open sim. Oh and metrics accessible to in world devs to back up decisions regarding establishing limits would be good so we can run the tests ourselves and see if we come up with different results. Like how scriptless attachments don't slow me down on tp or crossings so to me the issue people have, as proven by having them get rid of the lousy scripts infesting hair and shoes and then them wearing the scriptless attachments while teleporting and they stop having issues is important. Just making assumptions all attachments are the cause of all issues is an error since the issue appears to solidly be associated with the scripts. >> Linden Lab will absolutely have the final word about what goes into >> the >>viewer. >> Sure. Of course. I for one have no expectation of LL putting in the jiggle feature. I don't even care because I don't use it nor any viewer with it. But I am one person. From my technical perspective opinion it is a hack and does not take into account chest/neck/pectoral attachments that may be part of an expensive oufit. Therefore it is not what I would call a professional feature because it interferes with or fails dominant use cases and requirements even though it is a very much in demand capability that keeps vast numbers of people from using your viewer as they openly state jiggle is why they do not use LL viewers. >> We're a multi-million dollar business with hundreds of thousands of >>customers, Yes. As long as we customers, as an aggregate group, decide to keep giving you all those millions of dollars. >> some kind of product management and quality control Really? Why do previously fixed defects keep coming back? There is one I have always wondered about. How many times has an LL dev fixed the broken high resolution snapshot feature the majority of businesses rely upon, or rather once upon a time relied upon, for product imagery to create effective marketing? That is just one defect I recall having been fixed 3 times and then obviously overwritten by someone's obsolete code from their hard drive. SQA, or apparent lack of it, is a frequent theme amongst LL bashing festivals in various forums I have seen. Since I am not in your building and privy to your actual processes I can only go by what is observed in your deliverables. As for product management? I can't really go into this topic without getting personal so I won't. BTW large groups of customers screaming at you is a serious symptom the board needs to concern themselves with. IMHO anyway. I suppose you can stop holding office hours and eliminate that issue if people won't maintain their professional bearing and sense of self control in meetings. Is LL even open to constructive feedback about all aspects of LL's product delivery? Or is this restricted only to what LL exposes for feedback? Since this list is OS dev then I am curious about where the feedback mechanisms will be for the other aspects of LL's service delivery. Thank you for the opportunity of having a dialog. - From: Oz Linden (Scott Lawrence) To: Henri Beauchamp Cc: opensource-dev@lists.secondlife.com Sent: Mon, August 16, 2010 2:56:25 PM Subject: Re: [opensource-dev] Open Viewer Development Announcement I've said this before, and I'll repeat it again here: Don't waste everyones time suggesting that we throw away Viewer 2, or that we revert the UI to Viewer 1. It is absolutely not going to happen, and any suggestion to that effect will be ignored. That does not mean that we don't recognize that some choices in V2 were not optimal, and that some probably need to be revisited, and we're open to doing that. But we will do it in the context of calm discussions of what problems exist and creative ideas for how to solve them. We are not moving backwa
Re: [opensource-dev] display names = the end of 1.x viewers?
Do I understand you correctly that new accounts can make their name anything including existing account names? From: Kelly Linden To: Jesse Barnett Cc: opensource-dev@lists.secondlife.com; Baloo Uriza Sent: Thu, August 19, 2010 11:27:21 AM Subject: Re: [opensource-dev] display names = the end of 1.x viewers? On Thu, Aug 19, 2010 at 4:18 AM, Jesse Barnett wrote: baloo198731.residentPlenty of names available. > I just wanted to point out that this theoretical new user's username would be baloo198731, it would not be baloo198731.resident. The 'Resident' isn't really a part of a new user's identity. It is only shown to viewers that do not support display names and legacy LSL script calls - in other words that last name is only there when required for backwards compatibility. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?
I hate replying to a policy thread here but will make this one time exception for my humble input for LL's consideration: What I think LL should consider is something in the TPV policy that prohibits any tpv from connecting to any non LL server for any reason when a LL grid is selected for login. This simple policy, if correctly followed, would have prevented the incident. It would also eliminate a tpv team from monitoring logins and usage but then where exactly did they get to do that in the first place? It is a missed policy bullet. There is no reason a client should connect to anything except an LL server when an LL grid is selected. LL needs to be totally security conscious about the login process and what rigid requirements must be met for connecting to the LL grids. I.e.; I watch my port activity. Everyone should. But not everyone would know what they are looking at. But had they been watching I bet they would have been wanting to know what all those connections to that host were all about right away. Had I been using Emerald and saw thirty something connections to iheartanime dot com appear I would have been raising hell immediately. What you connect to on the internet can be and is monitored sometimes and being open to forced connections to something really bad would be extremely unfortunate for many that have tom be squeaky clean. I use Kirstens and I don't even care much for it's connection for motd. However it does tell me when the latest release is available and that is very useful information. Maybe there is a way for LL to provide motd bullets for tpvs so they can get the word out about updates or something. There has to be a better way. Regards Ann Otoole InSL From: Brian McGroarty To: Thomas Grimshaw Cc: opensource-dev@lists.secondlife.com Sent: Sat, August 21, 2010 10:33:52 AM Subject: Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything? On Sat, Aug 21, 2010 at 7:04 AM, Thomas Grimshaw wrote: > Loading 1mb of content per user is hardly a denial of service attack. > Crosslinking occurs everywhere on the web, this is simply nothing but > paranoid bull. "Crosslinking" drops the context of hiding gibberish requests to a critic's website in a hidden frame that will never be revealed to the user. This isn't a mere hyperlink to another page or naively stealing someone else's image hosting. My read (but I'm no lawyer) is that this looks like 2.d.iii of http://secondlife.com/corporate/tpv.php and we're already having that discussion. If anyone can come up with specific reasons why this might have had legitimate reason to be there, or how this one could be yet another oversight or mistake, that would be helpful. I sure haven't heard any to date. -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Plugins/Modular architecture
Has this project code been brought forward to Visual Studio 2010? From: Oz Linden (Scott Lawrence) To: opensource-dev@lists.secondlife.com Sent: Fri, September 3, 2010 9:32:54 AM Subject: Re: [opensource-dev] Plugins/Modular architecture On 2010-09-03 9:14, Lawson English wrote: >On 9/2/10 8:13 AM, Talia Tokugawa wrote: >> [...] >> I know this has been suggested before as friends have suggested it. >> Why not make the viewer more Modular? Introduce a plugin architecture. >> Allow any user to "build" their own client that fits their needs and >> requirements. >> > Its a HUGE undertaking to do that. LL wasn't willing to tackle the issue > directly years ago and they probably don't have the resources to do it > now. It would have to be a community-lead effort and I'm not sure that > developers are willing to invest the time to refactor the viewer at that > level unless LL will be willing to seriously consider using the > resulting re-architectured viewer. Try us... ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Plugins/Modular architecture
Why would anyone be burning time on VS2008 when VS2010 is the current environment? From: Brendan Wilson To: OpenSource Mailing List Sent: Sat, September 4, 2010 9:00:33 AM Subject: Re: [opensource-dev] Plugins/Modular architecture Not yet they have just started working on bring it to VS2008 and even doing that is by a lot of effort from the OS community there even a jira on at least bring it to VS2008(vc90) From:opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Ann Otoole Sent: Friday, September 03, 2010 10:11 AM To: Oz Linden (Scott Lawrence); opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Plugins/Modular architecture Has this project code been brought forward to Visual Studio 2010? From:Oz Linden (Scott Lawrence) To: opensource-dev@lists.secondlife.com Sent: Fri, September 3, 2010 9:32:54 AM Subject: Re: [opensource-dev] Plugins/Modular architecture On 2010-09-03 9:14, Lawson English wrote: >On 9/2/10 8:13 AM, Talia Tokugawa wrote: >> [...] >> I know this has been suggested before as friends have suggested it. >> Why not make the viewer more Modular? Introduce a plugin architecture. >> Allow any user to "build" their own client that fits their needs and >> requirements. >> > Its a HUGE undertaking to do that. LL wasn't willing to tackle the issue > directly years ago and they probably don't have the resources to do it > now. It would have to be a community-lead effort and I'm not sure that > developers are willing to invest the time to refactor the viewer at that > level unless LL will be willing to seriously consider using the > resulting re-architectured viewer. Try us... ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3113 - Release Date: 09/04/10 02:34:00 ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Plugins/Modular architecture
you mean like the obsolete libraries that show up with tp SL viewers? Like the one that dumps a bunch of garbage in the root and then does not uninstall them? And that screws up the system forcing you to have to redu windows updates to overwrite the obsolete libs from 2005? From: Nicky Perian To: Ann Otoole ; Brendan Wilson ; OpenSource Mailing List Sent: Sat, September 4, 2010 1:14:14 PM Subject: Re: [opensource-dev] Plugins/Modular architecture Libraries, Libraries, Libraries and MS redistribution hell. From: Ann Otoole To: Brendan Wilson ; OpenSource Mailing List Sent: Sat, September 4, 2010 12:10:12 PM Subject: Re: [opensource-dev] Plugins/Modular architecture Why would anyone be burning time on VS2008 when VS2010 is the current environment? From: Brendan Wilson To: OpenSource Mailing List Sent: Sat, September 4, 2010 9:00:33 AM Subject: Re: [opensource-dev] Plugins/Modular architecture Not yet they have just started working on bring it to VS2008 and even doing that is by a lot of effort from the OS community there even a jira on at least bring it to VS2008(vc90) From:opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Ann Otoole Sent: Friday, September 03, 2010 10:11 AM To: Oz Linden (Scott Lawrence); opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Plugins/Modular architecture Has this project code been brought forward to Visual Studio 2010? From:Oz Linden (Scott Lawrence) To: opensource-dev@lists.secondlife.com Sent: Fri, September 3, 2010 9:32:54 AM Subject: Re: [opensource-dev] Plugins/Modular architecture On 2010-09-03 9:14, Lawson English wrote: >On 9/2/10 8:13 AM, Talia Tokugawa wrote: >> [...] >> I know this has been suggested before as friends have suggested it. >> Why not make the viewer more Modular? Introduce a plugin architecture. >> Allow any user to "build" their own client that fits their needs and >> requirements. >> > Its a HUGE undertaking to do that. LL wasn't willing to tackle the issue > directly years ago and they probably don't have the resources to do it > now. It would have to be a community-lead effort and I'm not sure that > developers are willing to invest the time to refactor the viewer at that > level unless LL will be willing to seriously consider using the > resulting re-architectured viewer. Try us... ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3113 - Release Date: 09/04/10 02:34:00 ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Retaining Newbies (Was: The Plan for Snowglobe)
Sitearm Madonna just hosted a discussion on this topic today. Perhaps you should contact Sitearm for a transcript. From: Dilly Dobbs To: Tateru Nino Cc: opensource-dev@lists.secondlife.com Sent: Sat, September 11, 2010 2:39:10 PM Subject: Re: [opensource-dev] Retaining Newbies (Was: The Plan for Snowglobe) On 9/11/2010 1:11 PM, Tateru Nino wrote: >Well, as far as this mailing list goes, it should largely be kept to > viewer features/changes/improvements. Anything that happens beyond the > viewer is kind of out-of-scope. > > On 12/09/2010 4:05 AM, Robert Martin wrote: >> On Sat, Sep 11, 2010 at 1:52 PM, dilly dobbs wrote: >>> We all seem like intelligent adults that could come to an agreement on how >>> to add priority to the issues that we would like to see addressed. And yes >>> i work in an Agile dev software shop so im sorry about the lingo. >>> Opinions, and ideas on this ? >> I would like to put my paws into this kind of thing could we get an >> indoor type inworld location for this?? >> Any one that would like to participate in something like this please feel free to send me an IM in world and we can get the ball rolling. Dilly Dawes in world Thanks Dilly -- I love deadlines. I like the whooshing sound they make as they fly by Douglas Adams ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Severe water flicker in recent development build
I am not in the fan club of miring Second Life in the past. Another reason people don't stay is because all the current video games look so much better. However that has nothing to do with something working right on one build and then not working right on the next build and then trying to hide the defective coding by forcing settings to a higher level. I'm a little taken aback that such a tactic would be suggested. Why can't someone, specifically whoever made the changes, do a diff and look at the changes and come to a comprehension of exactly why this behavior commenced? (Why when I was a group development manager at the evil empire we had to walk a mile in the snow to fetch a pail of electricity to run the build system with and nm) From: Oz Linden (Scott Lawrence) To: Esbee Linden (Sarah Hutchinson) ; opensource-dev Sent: Sun, September 12, 2010 9:22:22 AM Subject: [opensource-dev] Severe water flicker in recent development build I'm seeing what I believe is the same problem described in SNOW-745 in our current development viewer. Second Life 2.1.2 (209297) I added some detail to the issue description. It's very irritating. I think we need to do something about it (might we be able to force Atmospheric Shaders to 'on'? That appears to suppress the problem). ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Snowstorm - Product Engine?
What is this "Product Engine" I see references to (made apparently by team shining) in the Scrum summaries? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Snowstorm - Product Engine?
But the question is what is the "Product Engine"? (I've seen the pics of those kids over there doing the work. They look like they like to have fun.) From: Yoz Grahame To: Ann Otoole Cc: opensource-dev@lists.secondlife.com Sent: Thu, September 16, 2010 4:07:14 PM Subject: Re: [opensource-dev] Snowstorm - Product Engine? On 16 September 2010 13:04, Ann Otoole wrote: What is this "Product Engine" I see references to (made apparently by team shining) in the Scrum summaries? They're an external contract team doing engineering and QA work for us. -- Yoz ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Openjpeg/KDU the cold hard metrics
How many textures do you need? I bet I have a bunch that are perfectly OK for this purpose as well as for commercial use. And if you need more I can generate them using filters. I.e.; this is not a block. From: Robin Cornelius To: Sheet Spotter Cc: opensource-dev Sent: Wed, September 22, 2010 3:55:20 AM Subject: Re: [opensource-dev] Openjpeg/KDU the cold hard metrics On Wed, Sep 22, 2010 at 4:01 AM, Sheet Spotter wrote: > I would love to see Robin's test harness. I would also love to see the > images that failed with v2. For the record I cannot give you (or anyone else) the images that failed, I was testing against a random selection of images pulled from the texture cache (and yes i know how to get a complete image out the cache) i wanted it to be a fair cross section of real SL textures not contrived test cases. I can probably people on an individual basis UUIDs of failed images but i'm afraid you will have to obtain the images yourselves I can't just go around distributing SL textures that are not mine. Maybe we can make a collection of test textures that we (the collective we) own, if an individual copyright holder has textures they can donate we can build a collection of test textures that can be used for metrics now and in the future. > > I started diving into the v2 branch of OpenJPEG a few days ago, after > research JPEG 2000 for a week. Tackling the bugs from the failed images > might be a good way to become more familiar with the source code. I can get full back traces to the offending lines which will be some help. > > I posted a very minor patch correcting some simple build problems with the > DLL version of OpenJPEG V2. >http://code.google.com/p/openjpeg/issues/detail?id=40 Yes i had to fix a few issues to get the dll to build, nothing major. > Thank you for publishing your results, Robin. They are encouraging me to > continue looking at OpenJPEG v2. Thanks OJP V2 looks like its worth the effort, so far using it with the viewer is failing badly. Encode now i've stopped it crashing is failing causing a "bake loop of hell" which consumes massive amounts of CPU time and spams the LL servers with bakes, so bad all around. As for the test harness, Yes let me tidy it slightly and I'll publish it, its really simple but i'm lazily working around one issue with error reporting currently. I also hopefully will have some new data tonight myself, looks like my results are artificially slow, BUT there remains a massive difference between KDU and openjpg, possibly worse than the x4 data i obtained, maybe in the order of x16-x20 slower but i need to rerun all the tests. This could also explain why SSE was showing odd results. Robin ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
The issue is all these crappy old obsolete resizers and texture changers. How about a different approach? Step one is complete. Some of us have worked and posted for free various versions of the fast resizers in one script. So there is no excuse for anyone to continue building new content using the obsolete versions. Step 2 would be to do the same for texture changers which is a different animal. Step 3 would be an official public awareness campaign to get creators on board. Step 4 might be some sort of program to get people to trade in their old script abusing shoes and hair on new versions that are not abusive. Step 5 might be to just kill the old abusive scripts when detected. Then LL can begin working on the other popular items notorious for infringing on others rights to a stable sim they are paying tier in. All this time an effort is going into mesh to get people to be aware of vertice counts. How about a similar effort around script resource abuse? Then you don't have to sandbag regions to get to a tool for estate owners to eject what they feel are script abusers. From: Kelly Linden To: Brandon Husbands Cc: opensource-dev@lists.secondlife.com Sent: Tue, September 28, 2010 1:55:57 AM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request There are multiple issues at play here: What I understand is that the viewer is flogging our servers to brute force build the data being requested. Yes, you get the results, yes it can take a bit of time for complex avatars or objects - and a lot more work is being done than is necessary both by the viewer and the server. When we look at implementing a feature request it is not in our best interest to just look at the quickest, dirtiest way to get the job done. We want to implement a feature that will work smoothly and be something we can support into the future. Our access to and responsibility for the server side as well as the viewer gives us both a better opportunity as well as increased responsibility. Just to be clear, the work done by other viewer teams is very good work and they have done a great job with the tools they have. I only wish we could have been quicker to expose better tools to them. Secondly, while some of our teams may have a primary focus on either the viewer or the server, other teams - such as the Land team - are built to focus on products as a whole. Estate, region and parcel tools are features we feel deserve to be looked at and evaluated as a product from end to end. These features almost always benefit from both viewer and server development. It is also beneficial to keep the backlogs of related functionality together so we can better prioritize the features and bugs that effect the Land product against each other. So, *yes* it is quite possible to implement this check in the viewer alone, and kudos to the team(s) that have done it. However, we feel obligated to do a more thorough solution by fixing the server and viewer together, and to prioritize this feature request against the many other feature requests for the Land product. - Kelly P.S. I am also not sure on the legal issues involved around the software licenses here. As far as I'm aware we still require a contributors agreement and it is not clear that the code added to the jira was actually written by the person who attached it to jira, whether that person has a contributors agreement or what license was attached to that code. At the very least I am guessing it is extremely bad form to submit code you don't own and didn't create into the jira. On Mon, Sep 27, 2010 at 10:24 PM, Brandon Husbands wrote: Just to iterate that it does work. > >[22:22] Counting scripts. Please wait. >[22:22] Counted scripts on object SL Exchange Magic Box white: 5 > >Works for any object. >The code even allows you if you have permissions to remove all scripts which >is >a desperately needed function with all the poorly scripted re-sizer scripts in >object. > > > >On Tue, Sep 28, 2010 at 12:18 AM, miss c wrote: > >It isn't a server feature, this works right now in all the OTHER viewers. I >attached like 10 files from the source code of all those viewers, the same >exact >files in each viewer that does this NOW. Did you even read my Jira?? I >worked >so hard to supply every bit of information. Unless you have allowed all these >other viewers access to the server code, I think there has been a mistake, >could >you please reread my Jira. >> >>TY >> >>Miss >> >> >> >> From: Brandon Husbands >>To: Sarah (Esbee) Hutchinson >>Cc: miss c ; opensource-dev@lists.secondlife.com >>Sent: Tue, September 28, 2010 12:12:33 AM >> >>Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature >>request >> >> >>Actually no its a viewer feature... >> >>http://hg.phoenixviewer.com/phoenix-sg/file/cc7894faa410/indra/newview/scr
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
I give you an image of what thousands of people are wearing and dozens more buy daily for less than L$200: http://annotoole.com/images/nuclearshoes.png (not my product btw) 11456kb each shoe? seriously? So 20 avatars in a club with these uses 458MB of region memory? Yes. A public awareness campaign is sorely needed. From: Ann Otoole To: opensource-dev@lists.secondlife.com Sent: Tue, September 28, 2010 2:52:53 AM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request The issue is all these crappy old obsolete resizers and texture changers. How about a different approach? Step one is complete. Some of us have worked and posted for free various versions of the fast resizers in one script. So there is no excuse for anyone to continue building new content using the obsolete versions. Step 2 would be to do the same for texture changers which is a different animal. Step 3 would be an official public awareness campaign to get creators on board. Step 4 might be some sort of program to get people to trade in their old script abusing shoes and hair on new versions that are not abusive. Step 5 might be to just kill the old abusive scripts when detected. Then LL can begin working on the other popular items notorious for infringing on others rights to a stable sim they are paying tier in. All this time an effort is going into mesh to get people to be aware of vertice counts. How about a similar effort around script resource abuse? Then you don't have to sandbag regions to get to a tool for estate owners to eject what they feel are script abusers. From: Kelly Linden To: Brandon Husbands Cc: opensource-dev@lists.secondlife.com Sent: Tue, September 28, 2010 1:55:57 AM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request There are multiple issues at play here: What I understand is that the viewer is flogging our servers to brute force build the data being requested. Yes, you get the results, yes it can take a bit of time for complex avatars or objects - and a lot more work is being done than is necessary both by the viewer and the server. When we look at implementing a feature request it is not in our best interest to just look at the quickest, dirtiest way to get the job done. We want to implement a feature that will work smoothly and be something we can support into the future. Our access to and responsibility for the server side as well as the viewer gives us both a better opportunity as well as increased responsibility. Just to be clear, the work done by other viewer teams is very good work and they have done a great job with the tools they have. I only wish we could have been quicker to expose better tools to them. Secondly, while some of our teams may have a primary focus on either the viewer or the server, other teams - such as the Land team - are built to focus on products as a whole. Estate, region and parcel tools are features we feel deserve to be looked at and evaluated as a product from end to end. These features almost always benefit from both viewer and server development. It is also beneficial to keep the backlogs of related functionality together so we can better prioritize the features and bugs that effect the Land product against each other. So, *yes* it is quite possible to implement this check in the viewer alone, and kudos to the team(s) that have done it. However, we feel obligated to do a more thorough solution by fixing the server and viewer together, and to prioritize this feature request against the many other feature requests for the Land product. - Kelly P.S. I am also not sure on the legal issues involved around the software licenses here. As far as I'm aware we still require a contributors agreement and it is not clear that the code added to the jira was actually written by the person who attached it to jira, whether that person has a contributors agreement or what license was attached to that code. At the very least I am guessing it is extremely bad form to submit code you don't own and didn't create into the jira. On Mon, Sep 27, 2010 at 10:24 PM, Brandon Husbands wrote: Just to iterate that it does work. > >[22:22] Counting scripts. Please wait. >[22:22] Counted scripts on object SL Exchange Magic Box white: 5 > >Works for any object. >The code even allows you if you have permissions to remove all scripts which >is >a desperately needed function with all the poorly scripted re-sizer scripts in >object. > > > >On Tue, Sep 28, 2010 at 12:18 AM, miss c wrote: > >It isn't a server feature, this works right now in all the OTHER viewers. I >attached like 10 files from the source code of all those viewers, the same >exact >files in each viewer that does this NOW. Did you even read my Jira?? I >
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
this isn't the place for that and LL needs to weigh in on things like this. It isn't the only one and one person LL openly promotes also sells over scripted shoes. If we are going after one we have to go after the ones LL promotes as well. Better for LL to step up first. From: Lance Corrimal To: opensource-dev@lists.secondlife.com Sent: Tue, September 28, 2010 5:06:06 AM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request Am Dienstag, 28. September 2010, 10:09:07 schrieb Ann Otoole: > I give you an image of what thousands of people are wearing and dozens more > buy daily for less than L$200: > http://annotoole.com/images/nuclearshoes.png (not my product btw) > > 11456kb each shoe? seriously? So 20 avatars in a club with these uses 458MB > of region memory? > > > Yes. A public awareness campaign is sorely needed. for that it needs to be known what shoe that is, who makes it, and the link to the SLU and blogorums post that makes the public actually aware... i mean, checking with the script floater AFTER you bought the shoes isn't going to make that creator aware of what shit he/she sells by reducing their sales. therefor: name shame and blame please. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Overview of JPEG 2000 codec
That would indicate we need region/location information panels accessible prior to teleport informing people of the expected bandwidth cost of the location. That way people on bandwidth limited plans can try to avoid going places that are costly. Want more traffic? Learn how to minimize texture counts. From: Lance Corrimal To: opensource-dev@lists.secondlife.com Sent: Fri, October 1, 2010 4:54:31 AM Subject: Re: [opensource-dev] Overview of JPEG 2000 codec Am Freitag, 1. Oktober 2010, 10:26:46 schrieb Yoz Grahame: > Another format referenced in the discussion is JPEG-XR (originally released > as "HD Photo" by Microsoft, now an ISO standard), which has all of the > above features. It might be worth doing a comparison, bearing in mind that > compression/quality ratio is not the only thing we care about. did you ever notice how may people are online in SL only at the beginning of the month? ...yes, that's because their connection gets capped after a few days of SL usage... because SL kicks up even more traffic than downloading pirated music 0.o or in other words, minimizing traffic through higher compression of textures could be a nice thing. bye, LC ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question about LOD debug setting
It simply depends on your computer and video card. I can run that setting at 4 with no noticeable difference. LL's quest to remain mired in circa 1999 graphics is admirable and noble and all but is costing SL/LL a vast amount of money. When mesh is rolled out and the inevitable "use all available resources" happens then I dare say SL will look a lot better but will probably lose the lower end anyway as they get tired and drop out because they can't have a decent experience and they choose alcohol, tobacco, reefer, and pizza over a decent gaming rig. As is said at Microsoft: Upgrade or die" This too shall happen with SL if SL is to survive a long time. If LL doesn't do it then someone else will. As for defaults yes the ultra default should be 4. LL recently changed the gpu_table.txt settings and any card that defults to ultra can more than handle RenderVolumeLODFactor at 4 with no noticeable impact. My GT240 on Kirstens with full shadows tweaked for realism gets a great frame rate with RenderVolumeLODFactor at 4. With shadows off and RenderVolumeLODFactor at 4 I get better than 29.97 FPS which is cinematic quality. However I get tired of ARC pundits spreading lies. Especially the ones saying mesh is low ARC since currently a theoretical mesh with 64 ktris/fr (64,000 polys per frame) will register less than 20 ARC depending on the settings and scripts involved. It is, after all, one damned prim to ARC. Oh, and BTW, the "ARC" will have to be changed to show mesh render cost and leave out the script cost. Make a script cost measure and a real ktris/fr worst case cost estimate measure for the avatar. And then we need parcel/region render cost metrics available as well. And an estimated bytes downloaded measure for people on capped bandwidth plans. The entire concept of impact metrics needs to be revisited and done right IMHO. From: leliel To: opensource-dev Sent: Sun, October 3, 2010 2:54:36 PM Subject: Re: [opensource-dev] Question about LOD debug setting On Sun, Oct 3, 2010 at 10:37 AM, Ponzu wrote: > I picked up a notecard that says to increase RenderVolumeLODFactor to 4. Is > this reasonable, do you think? And if so, why not increase the default a > bit (currently seems to be 1.125 It is reasonable, the default setting is a bit low. It varies with your graphics settings tho, 0 for low, 1.125 for mid & high, and 2 for ultra IIRC. I find 3 a good compromise between quality and performance. > Unlike increasing your draw distance, this will NOT create lag for yourself This however, is blatantly false. If rendering everything at full detail all the time didn't cause a drop in frame rate than why would we even bother with LOD? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question about LOD debug setting
Whats the jira for this defect you say exists that I have never once observed despite always using a setting of 4? There is a different debug setting calledRenderMaxNodeSize that produces the behavior you noted btw. It's default is 8192. Go lower and what you describe happens. From: Henri Beauchamp To: opensource-dev@lists.secondlife.com Sent: Sun, October 3, 2010 7:46:24 PM Subject: Re: [opensource-dev] Question about LOD debug setting On Sun, 3 Oct 2010 13:37:49 -0400, Ponzu wrote: > I picked up a notecard that says to increase RenderVolumeLODFactor to 4. Is > this reasonable, do you think? And if so, why not increase the default a > bit (currently seems to be 1.125 4 is OK for viewer v1.23.5. For Snowglobe (v1 and v2) and viewer 2, you should not use more than 3, because when using larger values, you will get graphic glitches with very small prims, especially with attachments: zooming out, they will vanish (as expected), but zooming back in, they will stay hidden 4 times out of 5 (zooming fast out and back in may get the small primes to appear again)... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Latest LL viewer beta has inventory count issues?
Anyone else noticing the inventory counts in the latest LL beta client are increasingly less than the count in the production release client and that cache clear does not correct it? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Latest LL viewer beta has inventory count issues?
Could be related to an existing pjira which is why I asked. However it is restricted to code after the LL production release candidate. I observe this in the latest Kirstens and the beta viewer. Deleting cache and refreshing in the production viewer produces the expected inventory count. Therefore it "appears" to be related to the newer code base only. However I do know asset data is "vanishing". I have a ticket open and never looked at in respect to a humble shoe texture I created and uploaded to SL that has vanished from the asset system. Easily replacable yes but highly annoying to know data seemingly vanishes into thin air that way. However the inventory record for that texture remains intact. When previewed or rezzed the texture just stays gray. No matter who tries to view it. That is an asset issue not an inventory issue. From: Ellla McMahon To: Ann Otoole Cc: opensource-dev@lists.secondlife.com Sent: Tue, October 5, 2010 3:41:06 PM Subject: Re: [opensource-dev] Latest LL viewer beta has inventory count issues? Recently reported against Second Life Server 10.9.10.210079SVC-6353Inventory fails to load fully It has been ongoing for well over a year > so maybe not the issue you are seeing. Reporter was using Second Life 2.2.0 (210127), so maybe this issue is more obvious in the 2.2 Beta. Older issue SVC-5902 Client gives up before finishing to load full inventory due to packet loss and request for a refresh button VWR-23074 Unloading item on my inventory, cause some useless relog. Other possibly related (to a slow/incomplete Inventory loading) issues * VWR-23308Can't rename a new folder * STORM-314Wear button in My Appearance greyed out On 5 October 2010 18:04, Ann Otoole wrote: Anyone else noticing the inventory counts in the latest LL beta client are increasingly less than the count in the production release client and that cache clear does not correct it? > > >___ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Where oh where has my rendering gone?
Or if you have an invidia card just use the control panel and make it gray scale. At least for viewing anyway. Might not work so good for filming. From: Joshua Bell To: Kent Quirk (Q Linden) Cc: "opensource-dev@lists.secondlife.com" Sent: Wed, October 6, 2010 11:57:34 AM Subject: Re: [opensource-dev] Where oh where has my rendering gone? On Tue, Oct 5, 2010 at 7:29 PM, Kent Quirk (Q Linden) wrote: Well, it's not quite like that. To pull this off, you'd have to take everywhere we set a color, and set it instead to its equivalent black and white value (there's a formula that's traditionally used, although there's no "correct" way to do it: Y = 0.3*R + 0.59*G + 0.11*B). You *might* be able to get away with modifying the LLColor4 constructor to do this, but it's probably going to have some surprising results when you assign a value and don't get the same value back. > How about post-processing every frame before the final swapBuffers call? That seems like it could be done with a shader and only touching a small amount of code. This would affect the UI as well as the world viewport, however, without some significant refactoring, but given that we already have some post-processing effects (glow, etc) perhaps there's already a good spot to slot this in? (Don't trust me too much, though, as I've never written a non-trivial shader and have never touched the viewer's render pipeline!) Of course, once you have monochrome output, you could tweak the shader and get sepia-toned rendering. Old-timey SL, anyone? -- Josh ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Local Lights
When is the last time anyone checked on local lights. I recall that 7 limit was removed a ways back and then during a discussion people were still saying there was a limit of 7. So I decided to test it. This is the current LL SLv2 Beta with ultra and everything settable in the UI maxed: http://annotoole.com/images/256locallightsonLLbeta.png This is in Kirstens S20(39) with the lighting on: http://annotoole.com/images/256locallightsonkirstensS20%2839%29.png Yes that is two hundred and fifty six local lights on in that screenshot. In the SLv2 Beta only 2 local lights worked at all. Any reason why the capabilities of the LL viewer keep being ratcheted down? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Project-MESH viewer
Are you planning to enable shine on prims with lighting/shadows on or is full lighting effects disable shininess something we need to accept as permanent and texture around? (Note that lighting in Kirstens also disables shine) From: Oz Linden (Scott Lawrence) To: opensource-dev@lists.secondlife.com Sent: Sat, October 16, 2010 11:01:38 AM Subject: Re: [opensource-dev] Project-MESH viewer On 2010-10-15 18:00, Trilo Byte wrote: > But on the flipside, the Project MESH viewer has working shadows for nVidia >GPU's on Mac (never happened before on any known config), and anti-aliasing's >fixed. If we could get that bit out of the mesh viewer and into the 2.2 >pipeline, we'd really be in great shape IMO. The AA fix is in the 2.2 pipeline (I did that merge) ... not sure about the other (since I don't know which change that was). ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Project-MESH viewer
There is no shine at all when lighting/shadows is enabled. Sorry. None whatsoever. Full shine black is just flat black. Full shine white is just flat white. Full shine textures are just the textures. It is completely broken. And this, in turn, "breaks content" that was sold with the expectation it was shiny. On the bright side it might make people rely less on shine to hide things that cannot be textured properly (sculpts generated from a wad of prims) or to cover a lack of decent texturing. I'm already discontinuing use of shine as much as possible because of this content breaker. And yes we will need the other aspects of texturing for mesh as soon as possible if possible. Wet looking skin with bulging veins on Cthu'lhu would indeed be awesome. But shine was broken once with windlight. Now it has been obliterated with deferred rendering. I don't expect to live long enough to see real time true reflectivity in Second Life. Like latex that actually reflects. Would be nice but there are miles and miles to go to get that gpu capability for real time translated to opengl and then farther to go to show up in Second life. Or third life or whatever this concept is called at that point 50 years from now if there is still an internet (doubtful) and civilians are allowed to be in possession of computers beyond what they are "chipped" with. From: Geenz Spad To: opensource-dev@lists.secondlife.com Sent: Sat, October 16, 2010 12:41:48 PM Subject: Re: [opensource-dev] Project-MESH viewer Shiny does work with the deferred renderer (or Lighting and Shadows as it's now called in the Mesh viewer). It's simply handled differently; it reflects light in the form of what's known as specular reflectance, instead of reflecting the sky environment (at one point it reflected both around 2008 and 2009). Different shiny settings effects the overall brightness and distribution of the specular exponent. On Sat, Oct 16, 2010 at 11:24 AM, Ann Otoole wrote: Are you planning to enable shine on prims with lighting/shadows on or is full lighting effects disable shininess something we need to accept as permanent and texture around? (Note that lighting in Kirstens also disables shine) > > > From: Oz Linden (Scott Lawrence) >To: opensource-dev@lists.secondlife.com >Sent: Sat, October 16, 2010 11:01:38 AM >Subject: Re: [opensource-dev] Project-MESH viewer > > > On 2010-10-15 18:00, Trilo Byte wrote: >> But on the flipside, the Project MESH viewer has working shadows for nVidia >>GPU's on Mac (never happened before on any known config), and anti-aliasing's >>fixed. If we could get that bit out of the mesh viewer and into the 2.2 >>pipeline, we'd really be in great shape IMO. > >The AA fix is in the 2.2 pipeline (I did that merge) ... not sure about >the other (since I don't know which change that was). > >___ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > > >___ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Flexi Prim Mesh Resolution
What is the purpose of the flexi prims mesh resolution slider in graphics preferences. It now appears to be forced to mid or low all the time and changing the slider has no observable effect whatsoever. Second Life 2.4.0 (213715) Nov 2 2010 19:22:14 (Second Life Development) ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
