Re: [opensource-dev] Upcoming depth-of-field feature
Awesome!! Haven't looked at it yet, but that is a very exciting prospect for a Yuletime Toy! Honestly, I really had put this on my list to santa. Cheers! Vector Hastings. -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Nyx Linden Sent: Tuesday, November 30, 2010 9:00 AM To: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Upcoming depth-of-field feature Depth of Field is a quick feature one of our devs developed while looking into anti-aliasing bugs. It didn't take a substantial amount of time away from bug-hunting, and should be useful for a variety of purposes (photography and machinima for starters). At this point it should be considered a toy, in that its a feature that hasn't yet been formally finished, debugged, qa'd, or had a good interface put on top of it. Feedback is appreciated for when we do prepare to polish it up of course. As always, you can see the changes we've made in the mesh branch in our public repository: http://hg.secondlife.com/mesh-development You can always get the latest successful build of our changes here (link is also on the wiki downloads page): http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/mesh-develop ment/latest.html Feedback is appreciated to be put into jira-form under the mesh beta project for specific bug reports and feature requests, or on the forums for any topics that could require discussion: http://blogs.secondlife.com/community/forums/mesh Thanks for noticing, and thanks for the feedback! -Nyx On 11/25/2010 06:54 PM, Ricky wrote: > Agreed, DOF is on my long-list not my short-list of things I'd like to > see done. However, I expect that SL's deferred rendering system has a > laundry list of issues. Just look at it's history; it's been little > more than a pet-project since it's inception. A pet project with the > capability to go far, but still just a pet project. Getting the > client into a stronger codebase (2.0) and then stabilized with very > little new features has been the largest pushes in recent history. > > In fact, we've (LL and OS devs,) been working stability for so many > months that it might be time to push for a cool, if small, new > feature. However, with the new level of visibility, it won't be as > much a surprise. I hope. From my reading here, most people don't like > surprises! :P Maybe something nice, like a good UI skinning system... > See http://wiki.secondlife.com/wiki/Skinning#Phase_2_-_Switchable_Skins > Or maybe a roll-out of meshes, but I suspect that's wishing too hard! > :P > > As to the original question about DoF, here's what is known: > http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=%22depth+of+field%22 +OR+DOF+site:secondlife.com > Which gives the following JIRAs: > https://jira.secondlife.com/browse/VWR-19244 PROFESSIoNAL TOOL: > Snapshot: add functions: Dynamic Focus, Depth of field and Blurr > https://jira.secondlife.com/browse/VWR-3921 photographic tools: DoF > > In VWR-3921 Adeon Writer pointed to this build of the mesh viewer: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/mesh-develop ment/rev/215482/index.html > > Ricky > Cron Stardust > > On Thu, Nov 25, 2010 at 3:11 PM, Geenz Spad wrote: > >> I wonder how awesome it'll run on top of the already awesome deferred >> renderer that has really awesome performance on really awesome video cards >> that have really awesome drivers? >> >> Honestly, as nifty as DOF is as far as the "pretty" factor is concerned, >> right now the deferred renderer needs a few more optimizations before any >> additional features are added to it, and it still needs a few more work >> arounds for buggy drivers (for example, successfully running the deferred >> renderer on ATI hardware still tends to vary from person to person, >> depending on their hardware and driver combination). On top of that, you >> still need a pretty powerful video card in order to really take advantage of >> it, though I think that really has to do with bottle necks within the >> rendering system as a whole, not just bottle necks presented by the deferred >> renderer its self (although deferred rendering does have it's own bottle >> necks, and SL's deferred renderer in particular presents a few interesting >> ones of its own due to its flexibility). >> >> On Thu, Nov 25, 2010 at 4:43 PM, Ricky wrote: >> >>> Things ARE getting fixed, just look at the daily scrum reports or the >>> progress tracking in the JIRA. Also take note that sometimes "adding" >>> a single feature
[opensource-dev] Problems with downloading kdu
Hello all, I'm trying to get back into this after almost 2 years not having compiled the client. The new wiki instructions are Awesome! Thanks to all. I'm trying to autobuild and getting this error: ERROR: failed to download http://s3-proxy.lindenlab.com/private-builds-secondlif e-com/hg/repo/3p-kdu-private/rev/221672/arch/CYGWIN/installer/kdu-6.4.1-wind ows- 20110218.tar.bz2 Can anyone point me to a fix? Thanks! Vector ___ 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] Problem with llmeshrepository.cpp (was "Problems with downloading kdu")
Thanks to help from this board, I'm past my kdu problem and on to what I think is probably a genuine source issue: When compiling, the following error occurs: .\indra\newview\llmeshrepository.cpp(2921): error C2660: 'LLConvexDecomposition::setMeshData' : function does not take 2 arguments Will someone be fixing this and can they ping the list when its ready? Cheers, Vector Hastings -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Vector Hastings Sent: Saturday, August 06, 2011 3:48 PM To: opensource-dev@lists.secondlife.com Subject: [opensource-dev] Problems with downloading kdu Hello all, I'm trying to get back into this after almost 2 years not having compiled the client. The new wiki instructions are Awesome! Thanks to all. I'm trying to autobuild and getting this error: ERROR: failed to download http://s3-proxy.lindenlab.com/private-builds-secondlif e-com/hg/repo/3p-kdu-private/rev/221672/arch/CYGWIN/installer/kdu-6.4.1-wind ows- 20110218.tar.bz2 Can anyone point me to a fix? Thanks! Vector ___ 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 love the text only viewers. Would hate to see them disappear. How about SLIM? I realize that can probably be categorized as a separate service that's not a "viewer," but you could also see it as a "chat only" viewer. Could a third-party text-only viewer be considered compliant with 1h if it matches SLIM's functionality? Vector -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Robin Cornelius Sent: Tuesday, February 23, 2010 1:44 PM To: Soft Linden Cc: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Third party viewer policy On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden wrote: > Mike's correct. > > If you see any wording that's ambiguous about that, let us know. Well there are many other issues another couple are :- 1h "Central to Second Life is the principle of shared experience. The services we provide through our viewers, for example, our Land Store, the LindeX exchange, and the Xstreet SL marketplace, are designed to enhance Residents' shared experience. We may ask you to make changes to your Third-Party Viewer if it disables certain of our services, or if we believe it is inconsistent with the principle of shared experience or otherwise negatively affects the Second Life user experience. If we do, you agree to make the changes we request." This kind of blocks text viewers as well, of which i author one, as clearly a text only viewer does not share the same experience as a full 3d viewer. Also any one using mono with libomv has an issue as that cannot get the adaptor mac address and passes a NULL mac address, in the past LL have allowed a null mac address as they knew of this problem, clearly now though thats a breach of 2c part i. 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] Third party viewer policy
Thank you Soft for working through this large thread so calmly. This seems like one of the more crucial areas of concern, and your response is reassuring. Cheers, Vector -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Soft Linden Sent: Wednesday, February 24, 2010 4:12 PM To: Morgaine Cc: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Third party viewer policy On Wed, Feb 24, 2010 at 4:30 PM, Morgaine wrote: > Soft, > > Please add to your list of issues to pass to Legal, a highlighted copy of > Clause 6 in the GPLv2 license, as well as a highlighted copy of the section > of the GPLv2 FAQ which addresses the relevant clause of the license with a > clear example of GPL non-compliance. [Search for "impose any further > restrictions" to find it]. > > TPV section 1c is dramatically incompatible with GPLv2 clause 6 because it > conflicts with this part of clause 6 (an extremely important term in all GPL > licenses), in the specific case where the "recipient" of the code is the > developer: > > "You may not impose any further restrictions on the recipients' exercise of > the rights granted herein." Legal doesn't intend this to be a restriction on anything but use of our service or eligibility for inclusion in the Viewer Directory. Context is important here. Even the maintainers of GNU telnet won't let someone use telnet to mess up the FSF's servers. Legal is aware that there has been confusion on this. There will be an update soon, which makes the terms more clear. ___ 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
