Re: [opensource-dev] DD Philosophy
Suggestion, have a version of the current advanced graphics settings, with "min" and "max" levels for each of the current options, and a fps target, as well as having a drop down for the priority of each. So for example, I might set DD to min 64m max of 256m, and a priority of "low," meaning that the viewer should reduce DD to keep fps. I might have particle settings, and set that with a priority of low, as well as min and max number of avatars to render and so on. On 6/17/11, Hitomi Tiponi wrote: > Please no automatic DD - there are two many variables and differing > circumstances for it ever to work. Much better to work on other ways of > improving fps e.g. selective updating of avatar movement. > ___ 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] Backport of Tattoo and Alpha support to v1.23 ?
Also most bald hair bases use an alpha texture. On Wed, Mar 10, 2010 at 6:54 AM, Lance Corrimal wrote: > Am Mittwoch, 10. März 2010 15:29:01 schrieb Glen Canaday: >> On the bright side - anyone making tattoos and understanding the alpha >> mask isn't wearing system hair... > > plain wrong, since you can't NOT wear system hair. > you can wear system hair of length 0, otherwise known as a "bald hair base". > the one you're wearing while creating an alpha layer in a viewer with this > unfinished patch becomes broken, and turns you into a cloud. > ___ > 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] Brown-bag meeting to continue dialog on TVPV
I think Boy Lane's beta suggestion is excellent, because it will also reduce the possibility of other problems with the meeting. On Sat, Apr 10, 2010 at 7:16 AM, Boy Lane wrote: > Yes, the betagrid does not require to clickwrap the new ToS/TPV, for the > simple > reason it is a months old snapshot of SL. It would suit the purpose of > having an > open and constructive discussion just fine, without forcing anyone to accept > TPV > in the first place. > > You may als ___ 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] Viewer blacklist to replace the TPV directory ?
There already seems to be a black list, it just isn't published. On Fri, Apr 30, 2010 at 7:08 AM, Jonathan Irvin wrote: > Just an idea I think would be cool is if LL made a tool (perhaps a script) > that users could click on if they suspected their viewer to be bad or > something and it would cause the viewer to send the info to LL for > investigation. > > Perhaps also LL can have hashes of the viewer source code. Should it not > match or something, it won't allow them to connect or it would be reported, > etc. > > Jonathan Irvin > > > ___ > 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] Banning by client
This is clearly a security hole that is being exploited, so it should be fixed. ___ 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] Migrating open development focus to 2.x
2.0 doesn't run on my machine, until it does, I couldn't work on it even if I desired to. Other people are in the same position. On Fri, May 28, 2010 at 11:59 AM, Aleric Inglewood wrote: > Hi Oz, > > I already communicated this clearly to merov, but I'll summarize it here: > > As you can see from > https://spreadsheets.google.com/ccc?key=0AgvC7hm5YZqcdHVXb05iTE0wTFc0bWptTW4tOTZuS3c&hl=en&ui=2#gid=0 > all my patches larger than one line, being > > VWR-14914 (SNOW-673) > SNOW-84 (SNOW-546), > SNOW-103 (SNOW-688), > SNOW-240, > SNOW-129 (SNOW-670) > SNOW-408, > SNOW-477, > VWR-12984 (SNOW-643) > > were like .. ignored. > > Merov ported VWR-14914, and I even helped with two others > because my friends started porting it... but basically: > > I'm not stupid and I try not to make the same mistake twice. > Therefore, I won't port my patches to 2.0 (for them to be ignored, > again in 3.0 or God knows), certainly not considering that I'm > not even using 2.0 (for reasons pointed out by others). > > So, to answer your question, in order to get me to contribute > to 2.0 Linden Lab will have to get their payed coders to port > my patches to 2.0 external (not SG, but the real thing), AND > fix the UI of 2.0 so it becomes interesting for me to use it > instead of 1.x). > > On Thu, May 27, 2010 at 11:50 PM, Oz Linden (Scott Lawrence) > wrote: >> >> I opened this in the 27 May IW open source meeting, and would like to >> invite wider and more specific feedback. >> >> It's fairly clear that Linden Lab doesn't have the resources to devote >> to active work on both Snowglobe 1.x and 2.x, and it's not efficient for >> the community as a whole to be splitting effort. >> >> I'd like to fairly quickly get to the point where all our new work is >> happening on the 2.x branch. That said, I understand that might leave >> behind things that the Snowglobe user/dev base wants and that some >> people are not happy with some elements of 2.x. What I'd like to know >> is... what needs to happen to make that choice that most people can be >> happy with? >> >> One of my goals is to increase the rate and volume at which Linden Lab >> can (and _does_) take changes from the open source base into the >> internal code, but unless we can keep everyone on the same branch, that >> will be much more difficult. >> >> Please respond to this thread with your favorite reasons not to move >> development to 2.x. We will review the list at the 6 June open source >> meeting with the goal of setting some priorities. >> >> >> >> To be clear... I don't object to anyone else working on 1.x at all; I'd >> just like to know why so that we can tempt them to join us on 2.x >> >> ___ >> 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
Re: [opensource-dev] display names = the end of 1.x viewers?
Many of the problems can be solved with options to put account name into a log, or make it visible in a tag. That way, if people want to know the unique identifier, they can see it, and can have it logged. Many of us are required to log conversations while at work, and having a real account name option would make second life compliant with standards that mandate having a log which tracks the identities of people we speak with. Display names do not meet that standard, account names do. On Sat, Aug 21, 2010 at 7:51 AM, Carlo Wood wrote: > ROFL - unique display names > > Well, I suggested the same, but per SIM -- not globally :p > Making them globally unique would kinda void the whole reason > they are being introduced imho. > > I think I saw a very strong argument posted here about not > automating anything though: It's near 100% sure that people > will be able to LOOK like having the same display name while > no computer will be able to notice that. > > I think that using a different color or rectangle around > display names (or user names) to differentiate them is the > way to go to make sure nobody will ever think that a display > name is someones user name. > > On Thu, Aug 19, 2010 at 08:08:07PM -0400, mysticaldem...@xrgrid.com wrote: >> Seems like twitter has a pretty good solution. Display names are unique. >> And >> your login account isn’t public so you have better security. Default your >> display name to your current SL name. After that people can request the name >> they want. As far as scripts, chat, everything else, that use your text >> version of your name, they all change on other systems and we get by. >> >> >> >> Mystical > > -- > Carlo Wood > ___ > 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] User Story: Improved Cache
Yes gutting the cache helps a lot. So does dumping a copy of the cache into a folder with the name of a sim, and on change to a non-contingous sim swapping where the cache points to so that suddenly the cache from the last visit to that sim is used. No, it's not compliant, because the most efficient case exposes all content. On Fri, Sep 17, 2010 at 10:10 AM, Ponzu wrote: > General concensus and *working code*. > > Go for it. > > On Thu, Sep 16, 2010 at 9:12 PM, Brandon Husbands wrote: >> You could technically watermark the images and have the display code just >> remove that mark. >> If it cant find the mark its considered corrupt. >> >> On Thu, Sep 16, 2010 at 6:45 PM, JB Hancroft wrote: >>> >>> > This viewer would get blacklisted before it ever got out the door. >>> >>> Because... it would be non-compliant in some way? >>> >>> On Thu, Sep 16, 2010 at 7:36 PM, Dale Mahalko wrote: I just don't have the motivation for it myself, but I would really like it if a 3rd party developer would gut out LL's texture cache and eliminate the VFS, and replace them with a simple disk cache that writes all assets in raw format, with files named by UUID on disk. * Decode all JPEG2000's once, to all levels of mipmap scale, and write the raw RGB mipmaps to disk as individual files (UUID+mipscale.bmp), discarding the source JP2's. * Decode all OGGs to WAV once, and write the raw WAV to disk, discarding the OGGs. * Oh, and don't ever delete any assets until your dedicated 2 terabyte cache drive is 99.99% full. * Let the local operating system deal with the file caching. If you have 4+ gig of system memory, let the OS manage it for caching frequently accessed world data. This cache would much simpler than the layered mess of caches currently used, and it would give a speed boost over the constant JP2 to RGB mipmap decoding and discarding that is in place now. Decode once and don't ever do it again. , But I know it is just a dream. LL will never let it happen since it will lay bare the data contents of every prim, texture, and object in the virtual world, rather than obfuscating asset storage within the current VFS / JP2 method. This viewer would get blacklisted before it ever got out the door. - Dale Mahalko / Scalar Tardis ___ 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 >> >> >> >> -- >> --- >> This email is a private and confidential communication. Any use of email may >> be subject to the laws and regulations of the United States. You may not >> Repost, Distribute nor reproduce any content of this message. >> --- >> --- >> >> ___ >> 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
Re: [opensource-dev] Openjpeg/KDU the cold hard metrics
Could you publish the test harness, I would like to try this on the mac with a mactools build of v2 On Tue, Sep 21, 2010 at 2:49 PM, Robin Cornelius wrote: > On Tue, Sep 21, 2010 at 7:44 PM, Aidan Thornton wrote: >> On 9/21/10, Robin Cornelius wrote: >>> I'm still not 100% sure why the build of openjpeg supplied by imprudence >>> is better than my builds on 2005. >> >> Imprudence is using the openjpeg SVN trunk version from a few months >> ago, which is essentially a pre-release version of openjpeg 1.4 and is >> slightly more optimised than 1.3. > > I built off revision 635 from trunk and tried with no SSE/SSE1 and > SSE2 as per my results, SSE1 on 2008 gives the best effect, SSE2 is a > disaster all around on my setup. > > 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] Openjpeg/KDU the cold hard metrics
Doing this out of a local cache would make it clearer what the time for the library is. I suspect these numbers understate the kdu advantage. On Wed, Sep 22, 2010 at 7:30 AM, Tateru Nino wrote: > > > On 22/09/2010 5:55 PM, Robin Cornelius wrote: >> 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) > It's not hard to do. I've got this little HTTP texture-proxy thing that > queries the local computers here to share local viewer caches and save > on bandwidth. And yes, the contents aren't the sort of thing you want to > pass around willy-nilly. > > -- > Tateru Nino > http://dwellonit.taterunino.net/ > > ___ > 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
