Re: [opensource-dev] STORM-151 : KDU v6.4.1 upgrade update
The build from yesterday works great! Second Life 2.4.0 (215468) Nov 23 2010 20:17:31 (Second Life Developer) Release Notes You are at 255,699.0, 255,436.0, 21.0 in Sandbox Goguen located at sim9026.agni.lindenlab.com (216.82.41.202:13004) Second Life RC Magnum 10.11.09.214391 Release Notes CPU: Intel(R) Core(TM)2 Quad CPU Q9000 @ 2.00GHz (1995.01 MHz) Memory: 6142 MB OS Version: Microsoft Windows 7 64-bit (Build 7600) Graphics Card Vendor: ATI Technologies Inc. Graphics Card: ATI Mobility Radeon HD 4650 Windows Graphics Driver Version: 8.14.0010.0678 OpenGL Version: 2.1.8787 libcurl Version: libcurl/7.20.1 OpenSSL/0.9.8j zlib/1.2.3 J2C Decoder Version: KDU Audio Driver Version: FMOD version 3.75 Qt Webkit Version: 4.6 (version number hard-coded) Voice Server Version: Vivox 3.2.0002.9361 Built with MSVC version 1400 Packets Lost: 273/17,198 (1.6%) ___ 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] [WIKI] 'Downloading test builds ' vs. 'Linden_Lab_Official:Alternate_Viewers'
Wouldn't be appropriate to merge together these pages, or a part of them? Maybe using a template, to avoid duplicated and out-of-date content. http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers http://wiki.secondlife.com/wiki/Downloading_test_builds They both offer links to open-source experimental viewers and development builds - it would be cool to have the whole list available in a single page. Sorry if I'm not clear - I'm not asking to delete any page, just to get a 100%comprehensive list in a single place. Opensource Obscure ___ 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] Date-time stamp
When compiling with Visual Studio (2005) where and what would I add to have a message printed out when the compiler begins working along the lines of Build started on [date] [time] ___ 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] Upcoming depth-of-field feature
Thanks to BlakOpal today I saw these very cool images: http://twitpic.com/3a0vag/full http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/5542853119016406770 http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/5543062518728480114 Where can I find more information about this depth-of-field feature? (wiki pages, blog/forums, JIRA...) It really looks good. I'm going to download a test build now. Thanks in advance Opensource Obscure ___ 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] 'Close' button doesn't work after setting Custom port in Preferences > Setup > Network
I just filed https://jira.secondlife.com/browse/VWR-23993 Got notice of it on Linux; a friend just confirmed it on Windows. I'd think this bug is recent, as in a few weeks. Before then, I was using the 'Custom Port' feature with no problems. Then I temporarily replaced my router, stopped using the feature, and only got aware of it today when I enabled it on a fresh viewer install. Anyway, I could see it on various releases: 2.3 (official), 2.4 (mesh), 2.5 (snowstorm). The 'Custom Port' option itself seems to work: even if you shut down the viewer, your setting sticks when you restart it. Problem is you can't close the floater and the Preferences window. Opensource Obscure ___ 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] Upcoming depth-of-field feature
Oh good, let's add more features instead of either optimizing things or fixing things. Rob On 11/25/2010 8:56 AM, Opensource Obscure wrote: > Thanks to BlakOpal today I saw these very cool images: > http://twitpic.com/3a0vag/full > > http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/5542853119016406770 > > http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/5543062518728480114 > > Where can I find more information about this depth-of-field > feature? (wiki pages, blog/forums, JIRA...) > > It really looks good. I'm going to download a test build now. > > > Thanks in advance > Opensource Obscure > ___ > 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] Upcoming depth-of-field feature
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 will often resolve several bugs and feature requests. For instance the Deferred rendering channel will add the ability to have greater than 7 light-sources, solving several issues with facelights and other lights taking out room lighting. As to optimization, things are pretty optimized. Yes, they CAN get better, but without a major restructuring of how content is created, we will never have the high render rates found in the online and offline games. Even so, the work being done on upgrading KDU looks like it is improving load/render rates as it is. Don't forget that there are multiple people in multiple teams working on this program. Some are better at adding new features, and so are better utilized in that area. Some are better testers than coders, and so that's where they get used. Some, fairly rare, are really good at making existing code much better. All these people types are at work here, and putting them all into "optimizing or fixing things" would be a death-knell for the company. I'd say, instead of berating new (and very cool,) advancements, we should all applaud the work being done. At the very least it will make someone's day that much brighter. Just my opinion, Ricky Cron Stardust On Thu, Nov 25, 2010 at 12:34 PM, Rob Nelson wrote: > Oh good, let's add more features instead of either optimizing things or > fixing things. > > Rob > > On 11/25/2010 8:56 AM, Opensource Obscure wrote: >> Thanks to BlakOpal today I saw these very cool images: >> http://twitpic.com/3a0vag/full >> >> http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/5542853119016406770 >> >> http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/5543062518728480114 >> >> Where can I find more information about this depth-of-field >> feature? (wiki pages, blog/forums, JIRA...) >> >> It really looks good. I'm going to download a test build now. >> >> >> Thanks in advance >> Opensource Obscure >> ___ >> 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] Upcoming depth-of-field feature
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 will often resolve several bugs and feature requests. > For instance the Deferred rendering channel will add the ability to > have greater than 7 light-sources, solving several issues with > facelights and other lights taking out room lighting. > > As to optimization, things are pretty optimized. Yes, they CAN get > better, but without a major restructuring of how content is created, > we will never have the high render rates found in the online and > offline games. Even so, the work being done on upgrading KDU looks > like it is improving load/render rates as it is. > > Don't forget that there are multiple people in multiple teams working > on this program. Some are better at adding new features, and so are > better utilized in that area. Some are better testers than coders, > and so that's where they get used. Some, fairly rare, are really good > at making existing code much better. All these people types are at > work here, and putting them all into "optimizing or fixing things" > would be a death-knell for the company. > > I'd say, instead of berating new (and very cool,) advancements, we > should all applaud the work being done. At the very least it will > make someone's day that much brighter. > > Just my opinion, > Ricky > Cron Stardust > > On Thu, Nov 25, 2010 at 12:34 PM, Rob Nelson > wrote: > > Oh good, let's add more features instead of either optimizing things or > > fixing things. > > > > Rob > > > > On 11/25/2010 8:56 AM, Opensource Obscure wrote: > >> Thanks to BlakOpal today I saw these very cool images: > >> http://twitpic.com/3a0vag/full > >> > http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/5542853119016406770 > >> > http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/5543062518728480114 > >> > >> Where can I find more information about this depth-of-field > >> feature? (wiki pages, blog/forums, JIRA...) > >> > >> It really looks good. I'm going to download a test build now. > >> > >> > >> Thanks in advance > >> Opensource Obscure > >> ___ > >> 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 > ___ 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] Upcoming depth-of-field feature
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-development/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 will often resolve several bugs and feature requests. >> For instance the Deferred rendering channel will add the ability to >> have greater than 7 light-sources, solving several issues with >> facelights and other lights taking out room lighting. >> >> As to optimization, things are pretty optimized. Yes, they CAN get >> better, but without a major restructuring of how content is created, >> we will never have the high render rates found in the online and >> offline games. Even so, the work being done on upgrading KDU looks >> like it is improving load/render rates as it is. >> >> Don't forget that there are multiple people in multiple teams working >> on this program. Some are better at adding new features, and so are >> better utilized in that area. Some are better testers than coders, >> and so that's where they get used. Some, fairly rare, are really good >> at making existing code much better. All these people types are at >> work here, and putting them all into "optimizing or fixing things" >> would be a death-knell for the company. >> >> I'd say, instead of berating new (and very cool,) advancements, we >> should all applaud the work being done. At the very least it will >> make someone's day that much brighter. >> >> Just my opinion, >> Ricky >> Cron Stardust >> >> On Thu, Nov 25, 2010 at 12:34 PM, Rob Nelson >> wrote: >> > Oh good, let's add more features instead of either optimizing things or >> > fixing things. >> > >> > Rob >> > >> > On 11/25/2010 8:56 AM, Opensource Obscure wrote: >> >> Thanks to BlakOpal today I saw these very cool images: >> >> http://twitpic.com/3a0vag/full >> >> >> >> http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/5542853119016406770 >> >> >> >> http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/5543062518728480114 >> >> >> >> Where can I find more information about this depth-of-field >> >> feature? (wiki pages, blog/forums, JIRA...) >> >> >> >> It really looks good. I'm going to download a test build now. >> >> >> >> >> >> Thanks in advance >> >> Opensource Obscure >> >> ___
Re: [opensource-dev] 'Close' button doesn't work after setting Custom port in Preferences > Setup > Network
I can repo this on various windows versions as well. > Date: Thu, 25 Nov 2010 19:29:25 +0100 > From: o...@autistici.org > To: opensource-dev@lists.secondlife.com > Subject: [opensource-dev] 'Close' button doesn't work after setting Custom > port in Preferences > Setup > Network > > I just filed https://jira.secondlife.com/browse/VWR-23993 > > Got notice of it on Linux; a friend just confirmed it on Windows. > > I'd think this bug is recent, as in a few weeks. Before then, > I was using the 'Custom Port' feature with no problems. Then I > temporarily replaced my router, stopped using the feature, > and only got aware of it today when I enabled it on a fresh > viewer install. > Anyway, I could see it on various releases: 2.3 (official), > 2.4 (mesh), 2.5 (snowstorm). > > The 'Custom Port' option itself seems to work: even if you > shut down the viewer, your setting sticks when you restart it. > Problem is you can't close the floater and the Preferences window. > > Opensource Obscure > ___ > 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
