From nickyperian at yahoo.com Tue Jan 1 19:05:56 2013 From: nickyperian at yahoo.com (Nicky Perian) Date: Tue, 1 Jan 2013 19:05:56 -0800 (PST) Subject: [opensource-dev] [FIXED] sunshine-external colladadom boost filesystem3 undefines Linux64 In-Reply-To: <1356899342.80390.YahooMailNeo@web126106.mail.ne1.yahoo.com> References: <1356899342.80390.YahooMailNeo@web126106.mail.ne1.yahoo.com> Message-ID: <1357095956.98783.YahooMailNeo@web126101.mail.ne1.yahoo.com> fixed. reverted to an earlier version on colladadom that was linked with boost version 1.45 >________________________________ > From: Nicky Perian >To: SLDEV ; Kokua Viewer development discussion list >Sent: Sunday, December 30, 2012 2:29 PM >Subject: sunshine-external colladadom boost filesystem3 undefines Linux64 > > >I am building a linux 64 bit kokua merge of sunshine-external. I have a link issue with colladadom looking for boost filesystem3 functions. >The viewer is built with boost 1.52 and colladadom boost 1.48. This is not different than the LL source/build environment. Linux 32 builds with just a few tweaks but, using mostly LL prebuilt libraries.? > > >Boost 1.52 dropped filesystem2 and filesystem3 and just builds as filesystem without the 2/3 source code split and dropped the deprecated directive. > > >/home/nicky/kokua-sunshine-external/build-linux-x86_64/packages/lib/release/libcollada14dom.so: undefined reference to `boost::filesystem3::detail::status(boost::filesystem3::path const&, boost::system::error_code*)' >/home/nicky/kokua-sunshine-external/build-linux-x86_64/packages/lib/release/libcollada14dom.so: undefined reference to `boost::filesystem3::path::parent_path() const' >/home/nicky/kokua-sunshine-external/build-linux-x86_64/packages/lib/release/libcollada14dom.so: undefined reference to `boost::filesystem3::detail::create_directories(boost::filesystem3::path const&, boost::system::error_code*)' >/home/nicky/kokua-sunshine-external/build-linux-x86_64/packages/lib/release/libcollada14dom.so: undefined reference to `boost::filesystem3::detail::rename(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::system::error_code*)' >/home/nicky/kokua-sunshine-external/build-linux-x86_64/packages/lib/release/libcollada14dom.so: undefined reference to `boost::filesystem3::detail::create_directory(boost::filesystem3::path const&, boost::system::error_code*)' >/home/nicky/kokua-sunshine-external/build-linux-x86_64/packages/lib/release/libcollada14dom.so: undefined reference to `boost::filesystem3::detail::remove_all(boost::filesystem3::path const&, boost::system::error_code*)' >/home/nicky/kokua-sunshine-external/build-linux-x86_64/packages/lib/release/libcollada14dom.so: undefined reference to `boost::filesystem3::detail::remove(boost::filesystem3::path const&, boost::system::error_code*)' >collect2: ld returned 1 exit status >make[2]: *** [newview/kokua-bin] Error 1 >make[1]: *** [newview/CMakeFiles/kokua-bin.dir/all] Error 2 >make: *** [all] Error 2 >ERROR: building default configuration returned 2 >For more information: try re-running your command with --verbose or --debug > > >I have tried rebuilding colladadom using boost 1.52. That corrects the filesystem undefines but, then there is a problem libxml2 undefines. > > >Anyone have suggestions?? > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130101/4ecbaee4/attachment.htm From Lance.Corrimal at eregion.de Sun Jan 6 02:56:31 2013 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 06 Jan 2013 11:56:31 +0100 Subject: [opensource-dev] gcc 4.7.1: lotsa warnings about boost Message-ID: <150836450.ovYWpUx2da@sai> Hi, Whenever I'm building the current development source on openSUSE 12.2 (read: with gcc 4.7.1) I get lots of warnings about boost-related things. Some of them I've been able to correct myself, others I'm stumped... the causes seem to be in 3p-boost itself, and i'd rather build with exactly the same libs as the lab... here's one of many examples: http://paste.opensuse.org/77018665 (it's way too long and unreadable for email) any ideas / tips / hints for me? google results seem to suggest something or the other about namespaces... cheers, LC From sldev at free.fr Sun Jan 6 05:22:26 2013 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 6 Jan 2013 14:22:26 +0100 Subject: [opensource-dev] gcc 4.7.1: lotsa warnings about boost In-Reply-To: <150836450.ovYWpUx2da@sai> References: <150836450.ovYWpUx2da@sai> Message-ID: <20130106142226.0fcc06f9.sldev@free.fr> On Sun, 06 Jan 2013 11:56:31 +0100, Lance Corrimal wrote: > Hi, > > Whenever I'm building the current development source on openSUSE 12.2 (read: > with gcc 4.7.1) I get lots of warnings about boost-related things. Some of > them I've been able to correct myself, others I'm stumped... the causes seem > to be in 3p-boost itself, and i'd rather build with exactly the same libs as > the lab... > > here's one of many examples: > > http://paste.opensuse.org/77018665 (it's way too long and unreadable for > email) > > any ideas / tips / hints for me? google results seem to suggest something or > the other about namespaces... There is currently a horrible mix of boost libraries versions used to build Linden's pre-built libraries (leading to many linking conflicts and errors), not to mention that LL inexplicably migrated (from boost v1.48 onwards) to shared boost libraries linking for the Linux viewer builds, resulting in an enormous 20Mb boost regex shared lib to be included into the Linux viewer package (while only 100Kb or so of this library's functions are actually used by the viewer: that's INSANE !)... My advice is therefore to stick with either boost v1.45 (for Linux and Windows) or v1.48 (for MacOS-X) pre-built libraries, that will link properly with the rest of LL's pre-built libraries for now. Henri. From sllists at boroon.dasgupta.ch Sun Jan 6 06:08:23 2013 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 06 Jan 2013 15:08:23 +0100 Subject: [opensource-dev] (was: gcc 4.7.1: lotsa warnings about boost) In-Reply-To: <150836450.ovYWpUx2da@sai> References: <150836450.ovYWpUx2da@sai> Message-ID: <50E98557.4020405@boroon.dasgupta.ch> On 06.01.2013 11:56, Lance Corrimal wrote: > Whenever I'm building the current development source on openSUSE 12.2 (read: > with gcc 4.7.1) I get lots of warnings about boost-related things. Some of > them I've been able to correct myself, others I'm stumped... the causes seem > to be in 3p-boost itself, and i'd rather build with exactly the same libs as > the lab... > > here's one of many examples: > > http://paste.opensuse.org/77018665 (it's way too long and unreadable for > email) > > any ideas / tips / hints for me? google results seem to suggest something or > the other about namespaces... For the problems indicated in the pasted log excerpt, I think they are caused by void intrusive_ptr_add_ref(LLIOPipe* p) and void intrusive_ptr_release(LLIOPipe* p) being used in boost/boost/smart_ptr/intrusive_ptr.hpp but being (forward) declared only after is included in indra/llmessage/lliopipe.h. Moving the forward declaration of these functions before that inclusion probably lets you get rid of the warning, but might require to move the forward declaration of class LLIOPipe even before both. See http://gcc.gnu.org/gcc-4.7/porting_to.html > section "Name lookup changes". Cheers, Borun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130106/670342b7/attachment.htm From nickyperian at yahoo.com Sun Jan 6 06:19:25 2013 From: nickyperian at yahoo.com (Nicky Perian) Date: Sun, 6 Jan 2013 06:19:25 -0800 (PST) Subject: [opensource-dev] gcc 4.7.1: lotsa warnings about boost In-Reply-To: <150836450.ovYWpUx2da@sai> References: <150836450.ovYWpUx2da@sai> Message-ID: <1357481965.11805.YahooMailNeo@web126102.mail.ne1.yahoo.com> I have not built with gcc 4.7.1 or openSUSE 12.2. I stay as close to LL's build environment as possible and use debian squeeze with gcc 4.5. Is your source repository current? If so, I can try to build. Can you build viewer-release?? I think siana commented about gcc 4.7 sometime back with some recommended build parameters. IIRC it was adding -fpermissive and a couple others. ?? >________________________________ > From: Lance Corrimal >To: opensource-dev at lists.secondlife.com >Sent: Sunday, January 6, 2013 4:56 AM >Subject: [opensource-dev] gcc 4.7.1: lotsa warnings about boost > >Hi, > > >Whenever I'm building the current development source on openSUSE 12.2 (read: >with gcc 4.7.1) I get lots of warnings about boost-related things. Some of >them I've been able to correct myself, others I'm stumped... the causes seem >to be in 3p-boost itself, and i'd rather build with exactly the same libs as >the lab... > >here's one of many examples: > >http://paste.opensuse.org/77018665? (it's way too long and unreadable for >email) > >any ideas / tips / hints for me? google results seem to suggest something or >the other about namespaces... > > >cheers, > >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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130106/1558bee0/attachment.htm From sllists at boroon.dasgupta.ch Sun Jan 6 06:23:38 2013 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 06 Jan 2013 15:23:38 +0100 Subject: [opensource-dev] gcc 4.7.1: lotsa warnings about boost In-Reply-To: <1357481965.11805.YahooMailNeo@web126102.mail.ne1.yahoo.com> References: <150836450.ovYWpUx2da@sai> <1357481965.11805.YahooMailNeo@web126102.mail.ne1.yahoo.com> Message-ID: <50E988EA.2040401@boroon.dasgupta.ch> On 06.01.2013 15:19, Nicky Perian wrote: > > ------------------------------------------------------------------------ > *From:* Lance Corrimal > *To:* opensource-dev at lists.secondlife.com > *Sent:* Sunday, January 6, 2013 4:56 AM > *Subject:* [opensource-dev] gcc 4.7.1: lotsa warnings about boost > > [...] > > http://paste.opensuse.org/77018665 (it's way too long and > unreadable for > email) > > [...] > > I think siana commented about gcc 4.7 sometime back with some > recommended build parameters. IIRC it was adding -fpermissive and a > couple others. -fpermissive is already in use here, or Lance would get errors rather than warnings. Cheers, B. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130106/ef145008/attachment.htm From carlo at alinoe.com Sun Jan 6 09:19:36 2013 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 6 Jan 2013 18:19:36 +0100 Subject: [opensource-dev] gcc 4.7.1: lotsa warnings about boost In-Reply-To: <150836450.ovYWpUx2da@sai> References: <150836450.ovYWpUx2da@sai> Message-ID: <20130106181936.74b38288@hikaru.localdomain> On Sun, 06 Jan 2013 11:56:31 +0100 Lance Corrimal wrote: > Hi, > > > Whenever I'm building the current development source on openSUSE 12.2 > (read: with gcc 4.7.1) I get lots of warnings about boost-related > things. Some of them I've been able to correct myself, others I'm > stumped... the causes seem to be in 3p-boost itself, and i'd rather > build with exactly the same libs as the lab... > > here's one of many examples: > > http://paste.opensuse.org/77018665 (it's way too long and unreadable > for email) > > any ideas / tips / hints for me? google results seem to suggest > something or the other about namespaces... This is just one of the many many examples showing that a lot of the Linden code was written by people who probably learned C++ in a 2 week course before starting to hack the viewer code. The solution is rather simple, really. Now I haven't looked at v-d in a while, but last time I compiled it I compiled it with gcc 4.7.2 and boost 1.49 and that gave me the same error as I see at the top of your paste (only looked at the first error by the way), which can be resolved by simply removing the nonsensical 'namespace boost'. Everywhere where you see namespace boost { // something with *intrusive* } remove the 'namespace boost {' and '}'. -- Carlo Wood From jaeger_reg at hotmail.com Sun Jan 6 14:49:04 2013 From: jaeger_reg at hotmail.com (Tank Master) Date: Sun, 6 Jan 2013 14:49:04 -0800 Subject: [opensource-dev] gcc 4.7.1: lotsa warnings about boost In-Reply-To: <20130106142226.0fcc06f9.sldev@free.fr> References: <150836450.ovYWpUx2da@sai>,<20130106142226.0fcc06f9.sldev@free.fr> Message-ID: Unfortunately, you can't use boost 1.45 ll provides because it lacks thread. Boost thread was added as part of Monty's updating the texture fetcher, and the ll boost repository already had been updated to include boost 1.48, so he just enabled packaging thread with is and used that version. Shortly afterword, boost got updated to 1.52 and code updated to use the new filepicker V3 api. ~Tank> Date: Sun, 6 Jan 2013 14:22:26 +0100 > From: sldev at free.fr > To: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] gcc 4.7.1: lotsa warnings about boost > > On Sun, 06 Jan 2013 11:56:31 +0100, Lance Corrimal wrote: > > > Hi, > > > > Whenever I'm building the current development source on openSUSE 12.2 (read: > > with gcc 4.7.1) I get lots of warnings about boost-related things. Some of > > them I've been able to correct myself, others I'm stumped... the causes seem > > to be in 3p-boost itself, and i'd rather build with exactly the same libs as > > the lab... > > > > here's one of many examples: > > > > http://paste.opensuse.org/77018665 (it's way too long and unreadable for > > email) > > > > any ideas / tips / hints for me? google results seem to suggest something or > > the other about namespaces... > > There is currently a horrible mix of boost libraries versions used to > build Linden's pre-built libraries (leading to many linking conflicts > and errors), not to mention that LL inexplicably migrated (from boost > v1.48 onwards) to shared boost libraries linking for the Linux viewer > builds, resulting in an enormous 20Mb boost regex shared lib to be > included into the Linux viewer package (while only 100Kb or so of this > library's functions are actually used by the viewer: that's INSANE !)... > > My advice is therefore to stick with either boost v1.45 (for Linux > and Windows) or v1.48 (for MacOS-X) pre-built libraries, that will > link properly with the rest of LL's pre-built libraries for now. > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130106/57d770b3/attachment.htm From sl.nicky.ml at googlemail.com Sun Jan 6 15:33:47 2013 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Mon, 7 Jan 2013 00:33:47 +0100 Subject: [opensource-dev] gcc 4.7.1: lotsa warnings about boost In-Reply-To: <150836450.ovYWpUx2da@sai> References: <150836450.ovYWpUx2da@sai> Message-ID: Try this and see if it helps http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/4fa73607d364 (skip the parts about FAA/FAD as you do not have those headers) Cheers, Nicky On Sun, Jan 6, 2013 at 11:56 AM, Lance Corrimal wrote: > Hi, > > > Whenever I'm building the current development source on openSUSE 12.2 > (read: > with gcc 4.7.1) I get lots of warnings about boost-related things. Some of > them I've been able to correct myself, others I'm stumped... the causes > seem > to be in 3p-boost itself, and i'd rather build with exactly the same libs > as > the lab... > > here's one of many examples: > > http://paste.opensuse.org/77018665 (it's way too long and unreadable for > email) > > any ideas / tips / hints for me? google results seem to suggest something > or > the other about namespaces... > > > cheers, > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130107/5f3dec52/attachment.htm From sldev at free.fr Sun Jan 6 16:05:47 2013 From: sldev at free.fr (Henri Beauchamp) Date: Mon, 7 Jan 2013 01:05:47 +0100 Subject: [opensource-dev] gcc 4.7.1: lotsa warnings about boost In-Reply-To: References: <150836450.ovYWpUx2da@sai> <20130106142226.0fcc06f9.sldev@free.fr> Message-ID: <20130107010547.e11a9b40.sldev@free.fr> On Sun, 6 Jan 2013 14:49:04 -0800, Tank Master wrote: > Unfortunately, you can't use boost 1.45 ll provides because it lacks > thread. True, but I recompiled boost from 3p-boost v1.45. You can use the pre-compiled libraries I'm using for the Cool VL Viewer, if you wish: Linux: http://sldev.free.fr/libraries/12650/boost-1.45.0-linux-20110310c.tar.bz2 (MD5: 5b4a0725053fe5076a12d591fd454ef5) Windows: http://sldev.free.fr/libraries/12650/boost-1.45.0-windows-20110310c.tar.bz2 (MD5: 1cad14c6c29fbc6588117bad831fa4b0) For Darwin, I'm currently using LL's v1.48: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-boost/rev/261457/arch/Darwin/installer/boost-1.48.0-darwin-20120710.tar.bz2 (MD5: 36aa500e13cdde61607b6e93065206ec) Henri. From Lance.Corrimal at eregion.de Mon Jan 7 01:06:25 2013 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 07 Jan 2013 10:06:25 +0100 Subject: [opensource-dev] gcc 4.7.1: lotsa warnings about boost In-Reply-To: References: <150836450.ovYWpUx2da@sai> Message-ID: <2576928.e2dJCJNR4X@sai> Thanks to you all, I got it settled now. Did anyone ever think of submitting CRs for that mess? bye, LC From Lance.Corrimal at eregion.de Mon Jan 7 07:39:18 2013 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 07 Jan 2013 16:39:18 +0100 Subject: [opensource-dev] gcc 4.7.1: lotsa warnings about boost In-Reply-To: <20130107010547.e11a9b40.sldev@free.fr> References: <150836450.ovYWpUx2da@sai> <20130107010547.e11a9b40.sldev@free.fr> Message-ID: <33117352.xSBegJeaCe@sai> Am Montag, 7. Januar 2013, 01:05:47 schrieb Henri Beauchamp: > On Sun, 6 Jan 2013 14:49:04 -0800, Tank Master wrote: > > Unfortunately, you can't use boost 1.45 ll provides because it lacks > > thread. > > True, but I recompiled boost from 3p-boost v1.45. You can use the > pre-compiled libraries I'm using for the Cool VL Viewer, if you wish: > Linux: > http://sldev.free.fr/libraries/12650/boost-1.45.0-linux-20110310c.tar.bz2 > (MD5: 5b4a0725053fe5076a12d591fd454ef5) > > Windows: > http://sldev.free.fr/libraries/12650/boost-1.45.0-windows-20110310c.tar.bz2 > (MD5: 1cad14c6c29fbc6588117bad831fa4b0) > > For Darwin, I'm currently using LL's v1.48: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-boost/rev > /261457/arch/Darwin/installer/boost-1.48.0-darwin-20120710.tar.bz2 (MD5: > 36aa500e13cdde61607b6e93065206ec) sadly enough the viewer does not compile with boost <= 1.48 on openSUSE 12.2 (gcc 4.7.1)... bye, LC From sldev at free.fr Wed Jan 9 08:26:51 2013 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 9 Jan 2013 17:26:51 +0100 Subject: [opensource-dev] Upcoming server side avatar baking In-Reply-To: <50CB9CEA.3000509@lindenlab.com> References: <50CB9CEA.3000509@lindenlab.com> Message-ID: <20130109172651.533611be.sldev@free.fr> On Fri, 14 Dec 2012 16:40:58 -0500, Oz Linden (Scott Lawrence) wrote: > For any of you developing viewers that are not in the TPV Directory and > so didn't get the notice there.... > > We have now made available the code for our upcoming server side baking > changes - you will need to update to be compatible with this in order > for users to see avatars correctly once the server side change is rolled > out to the main grid (some time > 8 weeks from now, but no date has been > set yet). > > See > https://wiki.secondlife.com/wiki/Project_Sunshine-Server_Side_Appearance > for information on this new code, and watch it for updates. The Linux viewer available for download from Sunshine's Wiki page has alas been compiled with a way too new glibc end refuse to run on my system (Mandriva 2010.2, glibc v2.11.1), aborting with: bin/do-not-directly-run-secondlife-bin: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by bin/do-not-directly-run-secondlife-bin) Could we please get a viewer compiled on the same build system as the one used for LL's other viewers ? Thank you. Henri. PS: I'm currently testing a server-side baking compatible Cool VL Viewer and trying to figure out a COF version missmatch issue (which ressembles this one: https://jira.secondlife.com/browse/SUN-3) that could be due to the inventory issues on Aditi: without a known, working viewer to compare with, it's hard to figure out if it's a bug in my backport or a bug in Aditi's inventory server... From Lance.Corrimal at eregion.de Wed Jan 9 09:48:58 2013 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 09 Jan 2013 17:48:58 -0000 Subject: [opensource-dev] Review Request: STORM-1926: When opening the landmarks floater first time after login, viewer freezes up for moments Message-ID: <20130109174858.2363.40641@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/614/ ----------------------------------------------------------- Review request for Viewer. Description ------- When you open the places floater for the first time after logging in it freezes the viewer for a period of time. That period seems to be related to the size of one's inventory and the number of landmarks in it. This addresses bug STORM-1926. http://jira.secondlife.com/browse/STORM-1926 Diffs ----- doc/contributions.txt 452e923131f3 indra/newview/llstartup.cpp 452e923131f3 Diff: http://codereview.secondlife.com/r/614/diff/ Testing ------- tested in the latest beta version of my own TPV, works as expected, with a beneficial side effect: the favorites bar gets populated right after login even after clearing cache. Thanks, Lance Corrimal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130109/ccc02d67/attachment.htm From robertltux at gmail.com Thu Jan 10 07:20:03 2013 From: robertltux at gmail.com (Robert Martin) Date: Thu, 10 Jan 2013 10:20:03 -0500 Subject: [opensource-dev] Current status on non-biped/giga|micro mesh avatars Message-ID: What is the current status on how SL handles mesh avatars that are not quite "standard"?? as an example if im using a Dire Wolf mesh avatar (and its properly rigged) will it work with quad animations?? Please do not just link to some semi random LL wiki page only link if it covers large/small and or quad avatars. -- Robert L Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130110/b8e10ee4/attachment.htm From stickman at gmail.com Thu Jan 10 12:43:17 2013 From: stickman at gmail.com (Stickman) Date: Thu, 10 Jan 2013 12:43:17 -0800 Subject: [opensource-dev] Current status on non-biped/giga|micro mesh avatars In-Reply-To: References: Message-ID: > What is the current status on how SL handles mesh avatars that are not quite > "standard"?? > > as an example if im using a Dire Wolf mesh avatar (and its properly rigged) > will it work with quad animations?? > > Please do not just link to some semi random LL wiki page only link if it > covers large/small and or quad avatars. Your subject line seems to vary a bit from the contents of the email, and I'm having difficulty interpreting your question. I'm going to assume the following: -You are making a quadruped rigged mesh avatar. -You intend to create "micro" and "macro" versions of this avatar by resizing the mesh and reimporting it. -You are making a complete set of custom quadruped animations. And I'm going to assume your actual question is as follows: -Can I use the same animations I've created for a normal sized avatar on the micro and macro versions of the same avatar? If you've experimented with uploading rigged mesh at all, you'll notice that there is a "height offset" value that you can set. When uploading a macro or micro avatar, the primarily change will be modifying this offset so the figure stands with their feet set on the ground. I have not done experimentation regarding animations and scaled meshes myself, but whether your animations can be reused or not depends on how the hip height of the animation itself is handled depending on how the hip height is configured when uploading rigged mesh. If the animation's height is a proportion of the configured height, then a crouching animation will put your tiny avatar just slightly further towards the ground, a normal avatar a larger distance but the same proportion, and so on. Otherwise, if it's closer to an absolute value, your tiny avatar is going to drop underground while playing the normal sized avatar's crouch animation. You will also notice, as you experiment with the animations, that the motion of the feet of the walk animation from a normal sized avatar no longer lines up with the ground on different sized avatars. The speed the agent traverses the landscape is not configurable, so giants and tinies move across the ground at the same speed. When you scale the figure up, it needs to move the legs slower. Same with scaling down -- the legs need to move faster. Assuming I understood your question right (feel free to rephrase it if I did not so someone else can take a stab at it), your answer is "yes and no." And also "depends." Do some experimentation based on the above and let us know the result. However, I'm certain some of the animations will simply not work and need to either have their height adjusted for the different sizes of avatars, or have their timing adjusted. If your question is specific to animations and rigged mesh scales as I assumed, you may also find further help inworld under a group related to your 3D modeling program, or the Avatar Maker's Guild. Stickman From sldev at free.fr Thu Jan 10 17:45:46 2013 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 11 Jan 2013 02:45:46 +0100 Subject: [opensource-dev] Out of FOV rotating child prims update bug (was: Re: OpenSource reciprocal help) In-Reply-To: <20121218103215.782656c3.sldev@free.fr> References: <50CB9CEA.3000509@lindenlab.com> <20121217094311.051b20aa.sldev@free.fr> <50CF8C43.1060707@lindenlab.com> <20121218103215.782656c3.sldev@free.fr> Message-ID: <20130111024546.352f40cd.sldev@free.fr> On Tue, 18 Dec 2012 10:32:15 +0100, Henri Beauchamp wrote: > On Mon, 17 Dec 2012 16:18:59 -0500, Oz Linden (Scott Lawrence) wrote: > > > No, we can't, sorry. > > Did you ever say "yes" and actually provide any kind of useful help > to an OpenSource developer ?... I'm yet to find a case in which that > happened... > > You, know, the time I spend sorting out LL's mess, I don't spend it > providing you with bugfixes (even if, because of the stupid CA stuff, > I must find convoluted ways to contribute, such as the private emails > I already sent to you to point out and explain nasty bugs in your > code). > > FYI, there are currently two nasty bugs in the renderer code that I > was investigating: > .../... > - another, even more serious bug, deals with scripted, punctually > moving objects (sliding and rotating doors, for example), which > position fails to be updated in the renderer when they are off > the camera FOV; click on an auto-closing door to open it, then > turn away from it so that it's no more in the FOV and wait till > it closes automatically, then turn around again to face it: > surprise, it appears as still open (but it's not: you'd bump > into it and right-clicking on the spot where it should be makes > it render again) ! For what it is worth, I identified the bug that was preventing step-rotating (llSetRot()) child primitives to be properly updated while out of the FOV (the similar, sliding doors, issue was solved in a recent patch that made its way to viewer-development lately). The problem is in lldrawable.cpp, around line 562. You need to change: else if (!isRoot() && (!mVObjp->getAngularVelocity().isExactlyZero() || dist_squared > 0.f)) for: else if (!isRoot() && (target_rot != old_rot || dist_squared > 0.f)) This is because prims rotating with llSetRot() don't have a velocity. Henri. From c at yotes.com Fri Jan 11 11:51:25 2013 From: c at yotes.com (Tofu Buzzard) Date: Fri, 11 Jan 2013 19:51:25 -0000 Subject: [opensource-dev] Review Request: OPEN-152 Fog is broken on water, and extra-broken on water in deferred rendering In-Reply-To: <20121202105345.6630.26356@domU-12-31-38-00-90-68.compute-1.internal> References: <20121202105345.6630.26356@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130111195125.4270.54281@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/611/#review1289 ----------------------------------------------------------- Anyone? - Tofu Buzzard On Dec. 2, 2012, 2:53 a.m., Tofu Buzzard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/611/ > ----------------------------------------------------------- > > (Updated Dec. 2, 2012, 2:53 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Made deferred water use the atmospheric helper shader functions properly, made fog calculation view-relative rather than absolute-position in deferred and non-deferred windlight shaders. > > > This addresses bug OPEN-152. > http://jira.secondlife.com/browse/OPEN-152 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/waterF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/waterV.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/environment/waterV.glsl UNKNOWN > indra/newview/llviewershadermgr.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/611/diff/ > > > Testing > ------- > > Tested with/without deferred rendering, with various sky presets. > > > Screenshots > ----------- > > before/after comparisons > http://codereview.secondlife.com/r/611/s/1/ > > > Thanks, > > Tofu Buzzard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130111/5ac39037/attachment.htm From geenz at geenzo.com Fri Jan 11 11:57:10 2013 From: geenz at geenzo.com (Geenz Spad) Date: Fri, 11 Jan 2013 19:57:10 -0000 Subject: [opensource-dev] Review Request: OPEN-152 Fog is broken on water, and extra-broken on water in deferred rendering In-Reply-To: <20121202105345.6630.26356@domU-12-31-38-00-90-68.compute-1.internal> References: <20121202105345.6630.26356@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130111195710.2362.67907@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/611/#review1291 ----------------------------------------------------------- Ship it! Looks good to me. - Geenz Spad On Dec. 2, 2012, 2:53 a.m., Tofu Buzzard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/611/ > ----------------------------------------------------------- > > (Updated Dec. 2, 2012, 2:53 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Made deferred water use the atmospheric helper shader functions properly, made fog calculation view-relative rather than absolute-position in deferred and non-deferred windlight shaders. > > > This addresses bug OPEN-152. > http://jira.secondlife.com/browse/OPEN-152 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/waterF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/waterV.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/environment/waterV.glsl UNKNOWN > indra/newview/llviewershadermgr.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/611/diff/ > > > Testing > ------- > > Tested with/without deferred rendering, with various sky presets. > > > Screenshots > ----------- > > before/after comparisons > http://codereview.secondlife.com/r/611/s/1/ > > > Thanks, > > Tofu Buzzard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130111/92a7cc38/attachment.htm From sldev at free.fr Fri Jan 11 12:13:16 2013 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 11 Jan 2013 21:13:16 +0100 Subject: [opensource-dev] Upcoming server side avatar baking In-Reply-To: <20130109172651.533611be.sldev@free.fr> References: <50CB9CEA.3000509@lindenlab.com> <20130109172651.533611be.sldev@free.fr> Message-ID: <20130111211316.5909ad48.sldev@free.fr> On Wed, 9 Jan 2013 17:26:51 +0100, Henri Beauchamp wrote: > The Linux viewer available for download from Sunshine's Wiki page has > alas been compiled with a way too new glibc end refuse to run on my > system (Mandriva 2010.2, glibc v2.11.1), aborting with: > bin/do-not-directly-run-secondlife-bin: /usr/lib/libstdc++.so.6: > version `GLIBCXX_3.4.15' not found > (required by bin/do-not-directly-run-secondlife-bin) > > Could we please get a viewer compiled on the same build system as the one > used for LL's other viewers ? > > Thank you. > > Henri. > > PS: I'm currently testing a server-side baking compatible Cool VL Viewer > and trying to figure out a COF version missmatch issue (which ressembles > this one: https://jira.secondlife.com/browse/SUN-3) that could be due > to the inventory issues on Aditi: without a known, working viewer to > compare with, it's hard to figure out if it's a bug in my backport or > a bug in Aditi's inventory server... Nevermind (though, having a propely built Linux Sunshine-viewer would still be a good thing), I figured out the bug (race condition between links creation in COF and rebake requests). The of the Cool VL Viewer v1.26.7.5 (experimental branch) has been released today with server-side baking support. Henri. From c at yotes.com Fri Jan 11 12:39:49 2013 From: c at yotes.com (Tofu Buzzard) Date: Fri, 11 Jan 2013 20:39:49 -0000 Subject: [opensource-dev] Review Request: VWR-29083 Make SSAO work better In-Reply-To: <20121202172312.7159.39203@domU-12-31-38-00-90-68.compute-1.internal> References: <20121202172312.7159.39203@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130111203949.2364.31008@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/settings.xml, line 7823 > > > > > > I still think it might be valuable to attenuate (HSV) saturation, but since it'd been stuck at 1.0 since forever and it doesn't look like it'll be exposed in Environment Settings anytime soon... *shrug* > > > > Used like this, RenderSSAOEffect might be entirely redundant with RenderSSAOFactor, if I remember correctly? I don't think HSV-modulating according to SSAO is valuable (either aesthetically or physically) - some sort of colour-grading function would be grand but it shouldn't be tied to SSAO. Only the 'V' part has ever been enabled (as released) as you say... RenderSSAOEffect and RenderSSAOFactor are unrelated. > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl, line 214 > > > > > > Where's the code where ssao_effect_mat had been constructed? (If it's not being used, it should probably be taken out too.) It was being constructed in pipeline.cpp, and the patch includes removal of that part. > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 127 > > > > > > The 'if' here might be problematic.. I remember some cards were choking on branches, thus the convoluted lines that looked like new = old + int(conditional)*value. (same for class1) > > > > Also, I could have sworn that there used to be comments here specifying what the non-mangled math originally was (a la the old softenLightF.glsl:206-214).... Our shaders are really branchy, that's really not a problem (on the target class). I don't strictly remember removing comments on the original maths, but the weighting (the only mathy part of this affair really) has changed radically at least twice since the original inline explanation, and should be simple enough to follow procedurally lately. :) > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 130 > > > > > > Won't using norm.xyz*diff raw like this cause false positives (from self-occlusion)? IIRC, that was why the old code used dot(samp-0.05*norm-pos, norm). (todo for self: render this for one sample to check...) (same for class1) I'm not sure I follow - but a sample candidate co-incident with the sample origin is disregarded. > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 132 > > > > > > Out of curiosity, why a minimum, instead of ex. "(angrel>0) ? distrel : 0.0" ? Seems odd in cases of 0 < angrel < distrel. (No longer using the sphere assumption?) The reasoning was that as a sample candidate draws nearer to the sample origin, the relevancy of its relative angle becomes overshadowed (so to speak :)), given that it's not really a point but a sampling of something (i.e. the sphere) with size whose extents are also increasingly blocking off the local area. Conversely, all distances being equal, the occlusion of the sample origin is proportional to the directness with which the sample candidate blocks its normal (the direction from which it *would* otherwise be drawing the most light). So the two relevancies modulate either other, the 'correct' mixing of the two in my head would be sqrt(angrel*distrel) but max(angrel,distrel) seemed a touch more pleasing and probably quicker. - Tofu ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/612/#review1288 ----------------------------------------------------------- On Dec. 2, 2012, 3:49 a.m., Tofu Buzzard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/612/ > ----------------------------------------------------------- > > (Updated Dec. 2, 2012, 3:49 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Use a different scheme for weighting SSAO samples, apply SSAO before fog is applied, fix a bug in the screen-space shadow/ssao smoothing offset where the 'checkerboard' stipple had been refactored incorrectly, change some default settings in line with the resulting visual changes. Also, improve comments a bit. :3 > > > This addresses bug VWR-29083. > http://jira.secondlife.com/browse/VWR-29083 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/llrender/llshadermgr.h UNKNOWN > indra/llrender/llshadermgr.cpp UNKNOWN > indra/newview/app_settings/settings.xml UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl UNKNOWN > indra/newview/pipeline.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/612/diff/ > > > Testing > ------- > > Been running with this for months on an assortment of nvidia hardware, linux only. > > > Thanks, > > Tofu Buzzard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130111/8e413acc/attachment.htm From geenz at geenzo.com Fri Jan 11 12:51:35 2013 From: geenz at geenzo.com (Geenz Spad) Date: Fri, 11 Jan 2013 20:51:35 -0000 Subject: [opensource-dev] Review Request: VWR-29083 Make SSAO work better In-Reply-To: <20121202172312.7159.39203@domU-12-31-38-00-90-68.compute-1.internal> References: <20121202172312.7159.39203@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130111205135.2366.32254@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 127 > > > > > > The 'if' here might be problematic.. I remember some cards were choking on branches, thus the convoluted lines that looked like new = old + int(conditional)*value. (same for class1) > > > > Also, I could have sworn that there used to be comments here specifying what the non-mangled math originally was (a la the old softenLightF.glsl:206-214).... > > Tofu Buzzard wrote: > Our shaders are really branchy, that's really not a problem (on the target class). I don't strictly remember removing comments on the original maths, but the weighting (the only mathy part of this affair really) has changed radically at least twice since the original inline explanation, and should be simple enough to follow procedurally lately. :) However, a general rule of thumb is if you can save a branch in a shader, then you should do so. My personal preference is to try and keep it to branches that have defined ARB instructions that a vendor's GLSL compiler will likely optimize to (which is limited to less than and greater than unfortunately). Though you're right, it's not much of a problem on class 2 hardware that can handle deferred. That said, is there a good reason for diff.z != 0.0 to *not* be diff.z > 0.0? - Geenz ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/612/#review1288 ----------------------------------------------------------- On Dec. 2, 2012, 3:49 a.m., Tofu Buzzard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/612/ > ----------------------------------------------------------- > > (Updated Dec. 2, 2012, 3:49 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Use a different scheme for weighting SSAO samples, apply SSAO before fog is applied, fix a bug in the screen-space shadow/ssao smoothing offset where the 'checkerboard' stipple had been refactored incorrectly, change some default settings in line with the resulting visual changes. Also, improve comments a bit. :3 > > > This addresses bug VWR-29083. > http://jira.secondlife.com/browse/VWR-29083 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/llrender/llshadermgr.h UNKNOWN > indra/llrender/llshadermgr.cpp UNKNOWN > indra/newview/app_settings/settings.xml UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl UNKNOWN > indra/newview/pipeline.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/612/diff/ > > > Testing > ------- > > Been running with this for months on an assortment of nvidia hardware, linux only. > > > Thanks, > > Tofu Buzzard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130111/c5134417/attachment-0001.htm From c at yotes.com Fri Jan 11 13:16:43 2013 From: c at yotes.com (Tofu Buzzard) Date: Fri, 11 Jan 2013 21:16:43 -0000 Subject: [opensource-dev] Review Request: VWR-29083 Make SSAO work better In-Reply-To: <20121202114957.6626.55980@domU-12-31-38-00-90-68.compute-1.internal> References: <20121202114957.6626.55980@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130111211643.2364.69131@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/612/ ----------------------------------------------------------- (Updated Jan. 11, 2013, 1:16 p.m.) Review request for Viewer. Changes ------- Updated patch with a bunch more comments, made settings reflect what I've actually been testing with, reconciled class1 and class2 better, and added a new quality improvement (disregard samples which are being taken from outside the screen extents - eliminates spurious SSAO fringe at screen edges at some angles). Description ------- Use a different scheme for weighting SSAO samples, apply SSAO before fog is applied, fix a bug in the screen-space shadow/ssao smoothing offset where the 'checkerboard' stipple had been refactored incorrectly, change some default settings in line with the resulting visual changes. Also, improve comments a bit. :3 This addresses bug VWR-29083. http://jira.secondlife.com/browse/VWR-29083 Diffs (updated) ----- doc/contributions.txt UNKNOWN indra/llrender/llshadermgr.h UNKNOWN indra/llrender/llshadermgr.cpp UNKNOWN indra/newview/app_settings/settings.xml UNKNOWN indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl UNKNOWN indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl UNKNOWN indra/newview/pipeline.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/612/diff/ Testing ------- Been running with this for months on an assortment of nvidia hardware, linux only. Thanks, Tofu Buzzard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130111/905a7e23/attachment.htm From c at yotes.com Fri Jan 11 13:22:24 2013 From: c at yotes.com (Tofu Buzzard) Date: Fri, 11 Jan 2013 21:22:24 -0000 Subject: [opensource-dev] Review Request: VWR-29083 Make SSAO work better In-Reply-To: <20130111211643.2364.69131@domU-12-31-38-00-90-68.compute-1.internal> References: <20130111211643.2364.69131@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130111212224.2364.60076@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/612/ ----------------------------------------------------------- (Updated Jan. 11, 2013, 1:22 p.m.) Review request for Viewer. Description (updated) ------- Use a different scheme for weighting SSAO samples, apply SSAO before fog is applied, fix a bug in the screen-space shadow/ssao smoothing offset where the 'checkerboard' stipple had been refactored incorrectly, change some default settings in line with the resulting visual changes. Disregard samples which are being taken from outside the screen extents - eliminates spurious SSAO fringe at screen edges at some angles. Micro-optimize the shadow co-ord calculation. Also, improve comments a bit. :3 This addresses bug VWR-29083. http://jira.secondlife.com/browse/VWR-29083 Diffs ----- doc/contributions.txt UNKNOWN indra/llrender/llshadermgr.h UNKNOWN indra/llrender/llshadermgr.cpp UNKNOWN indra/newview/app_settings/settings.xml UNKNOWN indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl UNKNOWN indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl UNKNOWN indra/newview/pipeline.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/612/diff/ Testing ------- Been running with this for months on an assortment of nvidia hardware, linux only. Thanks, Tofu Buzzard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130111/fd9c95da/attachment.htm From c at yotes.com Fri Jan 11 13:24:50 2013 From: c at yotes.com (Tofu Buzzard) Date: Fri, 11 Jan 2013 21:24:50 -0000 Subject: [opensource-dev] Review Request: VWR-29083 Make SSAO work better In-Reply-To: <20121202172312.7159.39203@domU-12-31-38-00-90-68.compute-1.internal> References: <20121202172312.7159.39203@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130111212450.2366.57341@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 127 > > > > > > The 'if' here might be problematic.. I remember some cards were choking on branches, thus the convoluted lines that looked like new = old + int(conditional)*value. (same for class1) > > > > Also, I could have sworn that there used to be comments here specifying what the non-mangled math originally was (a la the old softenLightF.glsl:206-214).... > > Tofu Buzzard wrote: > Our shaders are really branchy, that's really not a problem (on the target class). I don't strictly remember removing comments on the original maths, but the weighting (the only mathy part of this affair really) has changed radically at least twice since the original inline explanation, and should be simple enough to follow procedurally lately. :) > > Geenz Spad wrote: > However, a general rule of thumb is if you can save a branch in a shader, then you should do so. My personal preference is to try and keep it to branches that have defined ARB instructions that a vendor's GLSL compiler will likely optimize to (which is limited to less than and greater than unfortunately). Though you're right, it's not much of a problem on class 2 hardware that can handle deferred. > > That said, is there a good reason for diff.z != 0.0 to *not* be diff.z > 0.0? Added comments which explain diff.z != 0.0 somewhat! - Tofu ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/612/#review1288 ----------------------------------------------------------- On Jan. 11, 2013, 1:22 p.m., Tofu Buzzard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/612/ > ----------------------------------------------------------- > > (Updated Jan. 11, 2013, 1:22 p.m.) > > > Review request for Viewer. > > > Description > ------- > > Use a different scheme for weighting SSAO samples, apply SSAO before fog is applied, fix a bug in the screen-space shadow/ssao smoothing offset where the 'checkerboard' stipple had been refactored incorrectly, change some default settings in line with the resulting visual changes. Disregard samples which are being taken from outside the screen extents - eliminates spurious SSAO fringe at screen edges at some angles. Micro-optimize the shadow co-ord calculation. Also, improve comments a bit. :3 > > > This addresses bug VWR-29083. > http://jira.secondlife.com/browse/VWR-29083 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/llrender/llshadermgr.h UNKNOWN > indra/llrender/llshadermgr.cpp UNKNOWN > indra/newview/app_settings/settings.xml UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl UNKNOWN > indra/newview/pipeline.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/612/diff/ > > > Testing > ------- > > Been running with this for months on an assortment of nvidia hardware, linux only. > > > Thanks, > > Tofu Buzzard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130111/2071ac9e/attachment-0001.htm From c at yotes.com Fri Jan 11 13:25:38 2013 From: c at yotes.com (Tofu Buzzard) Date: Fri, 11 Jan 2013 21:25:38 -0000 Subject: [opensource-dev] Review Request: VWR-29083 Make SSAO work better In-Reply-To: <20121202172312.7159.39203@domU-12-31-38-00-90-68.compute-1.internal> References: <20121202172312.7159.39203@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130111212538.8809.75745@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 127 > > > > > > The 'if' here might be problematic.. I remember some cards were choking on branches, thus the convoluted lines that looked like new = old + int(conditional)*value. (same for class1) > > > > Also, I could have sworn that there used to be comments here specifying what the non-mangled math originally was (a la the old softenLightF.glsl:206-214).... > > Tofu Buzzard wrote: > Our shaders are really branchy, that's really not a problem (on the target class). I don't strictly remember removing comments on the original maths, but the weighting (the only mathy part of this affair really) has changed radically at least twice since the original inline explanation, and should be simple enough to follow procedurally lately. :) > > Geenz Spad wrote: > However, a general rule of thumb is if you can save a branch in a shader, then you should do so. My personal preference is to try and keep it to branches that have defined ARB instructions that a vendor's GLSL compiler will likely optimize to (which is limited to less than and greater than unfortunately). Though you're right, it's not much of a problem on class 2 hardware that can handle deferred. > > That said, is there a good reason for diff.z != 0.0 to *not* be diff.z > 0.0? > > Tofu Buzzard wrote: > Added comments which explain diff.z != 0.0 somewhat! And thanks for taking a look! - Tofu ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/612/#review1288 ----------------------------------------------------------- On Jan. 11, 2013, 1:22 p.m., Tofu Buzzard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/612/ > ----------------------------------------------------------- > > (Updated Jan. 11, 2013, 1:22 p.m.) > > > Review request for Viewer. > > > Description > ------- > > Use a different scheme for weighting SSAO samples, apply SSAO before fog is applied, fix a bug in the screen-space shadow/ssao smoothing offset where the 'checkerboard' stipple had been refactored incorrectly, change some default settings in line with the resulting visual changes. Disregard samples which are being taken from outside the screen extents - eliminates spurious SSAO fringe at screen edges at some angles. Micro-optimize the shadow co-ord calculation. Also, improve comments a bit. :3 > > > This addresses bug VWR-29083. > http://jira.secondlife.com/browse/VWR-29083 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/llrender/llshadermgr.h UNKNOWN > indra/llrender/llshadermgr.cpp UNKNOWN > indra/newview/app_settings/settings.xml UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl UNKNOWN > indra/newview/pipeline.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/612/diff/ > > > Testing > ------- > > Been running with this for months on an assortment of nvidia hardware, linux only. > > > Thanks, > > Tofu Buzzard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130111/fd419a1b/attachment.htm From c at yotes.com Fri Jan 11 13:34:06 2013 From: c at yotes.com (Tofu Buzzard) Date: Fri, 11 Jan 2013 21:34:06 -0000 Subject: [opensource-dev] Review Request: VWR-29083 Make SSAO work better In-Reply-To: <20130111212224.2364.60076@domU-12-31-38-00-90-68.compute-1.internal> References: <20130111212224.2364.60076@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130111213406.8814.36351@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/612/ ----------------------------------------------------------- (Updated Jan. 11, 2013, 1:34 p.m.) Review request for Viewer. Changes ------- Bring shadow settings more (totally!) in line with what I was actually testing with. At worst these reduce variance just for my benefit, at best (I hope) they are more finely-tuned for SL's current shadow shaders (given the landing of the ternary shadows). Description ------- Use a different scheme for weighting SSAO samples, apply SSAO before fog is applied, fix a bug in the screen-space shadow/ssao smoothing offset where the 'checkerboard' stipple had been refactored incorrectly, change some default settings in line with the resulting visual changes. Disregard samples which are being taken from outside the screen extents - eliminates spurious SSAO fringe at screen edges at some angles. Micro-optimize the shadow co-ord calculation. Also, improve comments a bit. :3 This addresses bug VWR-29083. http://jira.secondlife.com/browse/VWR-29083 Diffs (updated) ----- doc/contributions.txt UNKNOWN indra/llrender/llshadermgr.h UNKNOWN indra/llrender/llshadermgr.cpp UNKNOWN indra/newview/app_settings/settings.xml UNKNOWN indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl UNKNOWN indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl UNKNOWN indra/newview/pipeline.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/612/diff/ Testing ------- Been running with this for months on an assortment of nvidia hardware, linux only. Thanks, Tofu Buzzard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130111/b9057679/attachment.htm From c at yotes.com Fri Jan 11 14:00:30 2013 From: c at yotes.com (Tofu Buzzard) Date: Fri, 11 Jan 2013 22:00:30 -0000 Subject: [opensource-dev] Review Request: OPEN-159 / Faster, nicer Depth of Field Message-ID: <20130111220030.8812.1679@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/615/ ----------------------------------------------------------- Review request for Viewer. Description ------- This turns on bilinear filtering of the composited screen buffer used as the colour source for the depth-of-field effect (and its downscaled version). This simply means that we can get away with around half as many samples for the same quality of bokeh effect. The samples we do take express the desired radius more accurately too, so there aren't such glaring delineations in blurredness. To celebrate being about twice as fast, I've also upped the maximum fatness of the bokeh effect for situations of extreme defocus. So typical cases are around twice as fast, and the extreme bokeh situation is around the previous speed but with fatter highlights. This addresses bug OPEN-159. http://jira.secondlife.com/browse/OPEN-159 Diffs ----- indra/llrender/llpostprocess.cpp UNKNOWN indra/newview/app_settings/settings.xml UNKNOWN indra/newview/app_settings/shaders/class1/deferred/postDeferredF.glsl UNKNOWN indra/newview/pipeline.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/615/diff/ Testing ------- Been running like this for a while myself... Thanks, Tofu Buzzard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130111/587184e4/attachment-0001.htm From c at yotes.com Fri Jan 11 14:00:46 2013 From: c at yotes.com (Tofu Buzzard) Date: Fri, 11 Jan 2013 22:00:46 -0000 Subject: [opensource-dev] Review Request: OPEN-159 / Faster, nicer Depth of Field In-Reply-To: <20130111220030.8812.1679@domU-12-31-38-00-90-68.compute-1.internal> References: <20130111220030.8812.1679@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130111220046.2360.88609@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/615/ ----------------------------------------------------------- (Updated Jan. 11, 2013, 2 p.m.) Review request for Viewer. Description ------- This turns on bilinear filtering of the composited screen buffer used as the colour source for the depth-of-field effect (and its downscaled version). This simply means that we can get away with around half as many samples for the same quality of bokeh effect. The samples we do take express the desired radius more accurately too, so there aren't such glaring delineations in blurredness. To celebrate being about twice as fast, I've also upped the maximum fatness of the bokeh effect for situations of extreme defocus. So typical cases are around twice as fast, and the extreme bokeh situation is around the previous speed but with fatter highlights. This addresses bug OPEN-159. http://jira.secondlife.com/browse/OPEN-159 Diffs ----- indra/llrender/llpostprocess.cpp UNKNOWN indra/newview/app_settings/settings.xml UNKNOWN indra/newview/app_settings/shaders/class1/deferred/postDeferredF.glsl UNKNOWN indra/newview/pipeline.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/615/diff/ Testing ------- Been running like this for a while myself... Thanks, Tofu Buzzard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130111/48aafbda/attachment.htm From c at yotes.com Fri Jan 11 14:03:49 2013 From: c at yotes.com (Tofu Buzzard) Date: Fri, 11 Jan 2013 22:03:49 -0000 Subject: [opensource-dev] Review Request: OPEN-159 / Faster, nicer Depth of Field In-Reply-To: <20130111220046.2360.88609@domU-12-31-38-00-90-68.compute-1.internal> References: <20130111220046.2360.88609@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130111220349.4274.41749@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/615/#review1295 ----------------------------------------------------------- indra/llrender/llpostprocess.cpp Ah, yes. I added this assert to mark this function as broken because it ate some of my time just unobviously doing nothing. - Tofu Buzzard On Jan. 11, 2013, 2 p.m., Tofu Buzzard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/615/ > ----------------------------------------------------------- > > (Updated Jan. 11, 2013, 2 p.m.) > > > Review request for Viewer. > > > Description > ------- > > This turns on bilinear filtering of the composited screen buffer used as the colour source for the depth-of-field effect (and its downscaled version). > This simply means that we can get away with around half as many samples for the same quality of bokeh effect. The samples we do take express the desired radius more accurately too, so there aren't such glaring delineations in blurredness. > > To celebrate being about twice as fast, I've also upped the maximum fatness of the bokeh effect for situations of extreme defocus. So typical cases are around twice as fast, and the extreme bokeh situation is around the previous speed but with fatter highlights. > > > This addresses bug OPEN-159. > http://jira.secondlife.com/browse/OPEN-159 > > > Diffs > ----- > > indra/llrender/llpostprocess.cpp UNKNOWN > indra/newview/app_settings/settings.xml UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/postDeferredF.glsl UNKNOWN > indra/newview/pipeline.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/615/diff/ > > > Testing > ------- > > Been running like this for a while myself... > > > Thanks, > > Tofu Buzzard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130111/6ed8b5f4/attachment.htm From monty at lindenlab.com Fri Jan 11 14:26:33 2013 From: monty at lindenlab.com (Monty Brandenberg) Date: Fri, 11 Jan 2013 17:26:33 -0500 Subject: [opensource-dev] Review Request: OPEN-159 / Faster, nicer Depth of Field In-Reply-To: <20130111220349.4274.41749@domU-12-31-38-00-90-68.compute-1.internal> References: <20130111220046.2360.88609@domU-12-31-38-00-90-68.compute-1.internal> <20130111220349.4274.41749@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <50F09199.6030504@lindenlab.com> On 1/11/2013 5:03 PM, Tofu Buzzard wrote: > llassert_always(false); > > Ah, yes. I added this assert to mark this function as broken because it ate some of my time just unobviously doing nothing. http://catb.org/jargon/html/magic-story.html From celierra at gmail.com Fri Jan 11 14:55:25 2013 From: celierra at gmail.com (Celierra Darling) Date: Fri, 11 Jan 2013 22:55:25 -0000 Subject: [opensource-dev] Review Request: VWR-29083 Make SSAO work better In-Reply-To: <20121202172312.7159.39203@domU-12-31-38-00-90-68.compute-1.internal> References: <20121202172312.7159.39203@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130111225525.8809.8405@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/settings.xml, line 7823 > > > > > > I still think it might be valuable to attenuate (HSV) saturation, but since it'd been stuck at 1.0 since forever and it doesn't look like it'll be exposed in Environment Settings anytime soon... *shrug* > > > > Used like this, RenderSSAOEffect might be entirely redundant with RenderSSAOFactor, if I remember correctly? > > Tofu Buzzard wrote: > I don't think HSV-modulating according to SSAO is valuable (either aesthetically or physically) - some sort of colour-grading function would be grand but it shouldn't be tied to SSAO. Only the 'V' part has ever been enabled (as released) as you say... > RenderSSAOEffect and RenderSSAOFactor are unrelated. Hmm, there is some effect where saturation (seems to) decrease on AO'd areas, but that can be more illusion than physical. Tweaking it here would be either cancelling it or exaggerating it, and I can see the argument for avoiding it. Though there are real cases of artificial narrow-spectrum direct lighting + fuller-spectrum ambient light, like gas-discharge streetlamps at dusk or the such - thus my selfish lust for it getting exposed in environment settings... :p Looking at your comment, I think -Factor might be being used for something different from when I was using it, so never mind that. > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl, line 214 > > > > > > Where's the code where ssao_effect_mat had been constructed? (If it's not being used, it should probably be taken out too.) > > Tofu Buzzard wrote: > It was being constructed in pipeline.cpp, and the patch includes removal of that part. Whoops, thanks; not sure how I missed it. > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 130 > > > > > > Won't using norm.xyz*diff raw like this cause false positives (from self-occlusion)? IIRC, that was why the old code used dot(samp-0.05*norm-pos, norm). (todo for self: render this for one sample to check...) (same for class1) > > Tofu Buzzard wrote: > I'm not sure I follow - but a sample candidate co-incident with the sample origin is disregarded. 'angrel' and the larger sampling radius seem to have taken care of it. This was referring to the case where, for example, a sample pixel is picked that's 0.01 m away from the origin on the same triangle, and with a little rounding error, the sample ends up looking like a huge occluder. The old code has nothing analogous to 'angrel': there's an assumption that incoming ambient light is falling onto the sample origin equally from all directions. > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 127 > > > > > > The 'if' here might be problematic.. I remember some cards were choking on branches, thus the convoluted lines that looked like new = old + int(conditional)*value. (same for class1) > > > > Also, I could have sworn that there used to be comments here specifying what the non-mangled math originally was (a la the old softenLightF.glsl:206-214).... > > Tofu Buzzard wrote: > Our shaders are really branchy, that's really not a problem (on the target class). I don't strictly remember removing comments on the original maths, but the weighting (the only mathy part of this affair really) has changed radically at least twice since the original inline explanation, and should be simple enough to follow procedurally lately. :) > > Geenz Spad wrote: > However, a general rule of thumb is if you can save a branch in a shader, then you should do so. My personal preference is to try and keep it to branches that have defined ARB instructions that a vendor's GLSL compiler will likely optimize to (which is limited to less than and greater than unfortunately). Though you're right, it's not much of a problem on class 2 hardware that can handle deferred. > > That said, is there a good reason for diff.z != 0.0 to *not* be diff.z > 0.0? > > Tofu Buzzard wrote: > Added comments which explain diff.z != 0.0 somewhat! > > Tofu Buzzard wrote: > And thanks for taking a look! I see I should have been paying closer attention to the changes! :P Sorry if I'm struggling to catch up a bit. The same branch is also in class 1 too, FYI. I'm not sure what the definitions of the classes are these days.... > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 132 > > > > > > Out of curiosity, why a minimum, instead of ex. "(angrel>0) ? distrel : 0.0" ? Seems odd in cases of 0 < angrel < distrel. (No longer using the sphere assumption?) > > Tofu Buzzard wrote: > The reasoning was that as a sample candidate draws nearer to the sample origin, the relevancy of its relative angle becomes overshadowed (so to speak :)), given that it's not really a point but a sampling of something (i.e. the sphere) with size whose extents are also increasingly blocking off the local area. Conversely, all distances being equal, the occlusion of the sample origin is proportional to the directness with which the sample candidate blocks its normal (the direction from which it *would* otherwise be drawing the most light). > So the two relevancies modulate either other, the 'correct' mixing of the two in my head would be sqrt(angrel*distrel) but max(angrel,distrel) seemed a touch more pleasing and probably quicker. Thanks! You may want to put in that you're not presuming uniform incoming ambient light like the old code was. (Also, you forgot the sqrt in your comment if you were intending it to say the same thing as you said here?) - Celierra ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/612/#review1288 ----------------------------------------------------------- On Jan. 11, 2013, 1:34 p.m., Tofu Buzzard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/612/ > ----------------------------------------------------------- > > (Updated Jan. 11, 2013, 1:34 p.m.) > > > Review request for Viewer. > > > Description > ------- > > Use a different scheme for weighting SSAO samples, apply SSAO before fog is applied, fix a bug in the screen-space shadow/ssao smoothing offset where the 'checkerboard' stipple had been refactored incorrectly, change some default settings in line with the resulting visual changes. Disregard samples which are being taken from outside the screen extents - eliminates spurious SSAO fringe at screen edges at some angles. Micro-optimize the shadow co-ord calculation. Also, improve comments a bit. :3 > > > This addresses bug VWR-29083. > http://jira.secondlife.com/browse/VWR-29083 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/llrender/llshadermgr.h UNKNOWN > indra/llrender/llshadermgr.cpp UNKNOWN > indra/newview/app_settings/settings.xml UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl UNKNOWN > indra/newview/pipeline.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/612/diff/ > > > Testing > ------- > > Been running with this for months on an assortment of nvidia hardware, linux only. > > > Thanks, > > Tofu Buzzard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130111/61e916a1/attachment-0001.htm From celierra at gmail.com Fri Jan 11 15:08:00 2013 From: celierra at gmail.com (Celierra Darling) Date: Fri, 11 Jan 2013 23:08:00 -0000 Subject: [opensource-dev] Review Request: VWR-29083 Make SSAO work better In-Reply-To: <20121202172312.7159.39203@domU-12-31-38-00-90-68.compute-1.internal> References: <20121202172312.7159.39203@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130111230800.8813.1778@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 132 > > > > > > Out of curiosity, why a minimum, instead of ex. "(angrel>0) ? distrel : 0.0" ? Seems odd in cases of 0 < angrel < distrel. (No longer using the sphere assumption?) > > Tofu Buzzard wrote: > The reasoning was that as a sample candidate draws nearer to the sample origin, the relevancy of its relative angle becomes overshadowed (so to speak :)), given that it's not really a point but a sampling of something (i.e. the sphere) with size whose extents are also increasingly blocking off the local area. Conversely, all distances being equal, the occlusion of the sample origin is proportional to the directness with which the sample candidate blocks its normal (the direction from which it *would* otherwise be drawing the most light). > So the two relevancies modulate either other, the 'correct' mixing of the two in my head would be sqrt(angrel*distrel) but max(angrel,distrel) seemed a touch more pleasing and probably quicker. > > Celierra Darling wrote: > Thanks! You may want to put in that you're not presuming uniform incoming ambient light like the old code was. (Also, you forgot the sqrt in your comment if you were intending it to say the same thing as you said here?) Er, to be clearer, the old presumption was that ambient light would be falling onto the sample origin equally from all directions if not for the occluders that were sampled - thus no use of angrel. In hindsight, that seems a little dumb - to me, the way you're doing it is like using a better prior in the Bayesian sense. - Celierra ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/612/#review1288 ----------------------------------------------------------- On Jan. 11, 2013, 1:34 p.m., Tofu Buzzard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/612/ > ----------------------------------------------------------- > > (Updated Jan. 11, 2013, 1:34 p.m.) > > > Review request for Viewer. > > > Description > ------- > > Use a different scheme for weighting SSAO samples, apply SSAO before fog is applied, fix a bug in the screen-space shadow/ssao smoothing offset where the 'checkerboard' stipple had been refactored incorrectly, change some default settings in line with the resulting visual changes. Disregard samples which are being taken from outside the screen extents - eliminates spurious SSAO fringe at screen edges at some angles. Micro-optimize the shadow co-ord calculation. Also, improve comments a bit. :3 > > > This addresses bug VWR-29083. > http://jira.secondlife.com/browse/VWR-29083 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/llrender/llshadermgr.h UNKNOWN > indra/llrender/llshadermgr.cpp UNKNOWN > indra/newview/app_settings/settings.xml UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl UNKNOWN > indra/newview/pipeline.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/612/diff/ > > > Testing > ------- > > Been running with this for months on an assortment of nvidia hardware, linux only. > > > Thanks, > > Tofu Buzzard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130111/a27c7034/attachment.htm From latifer at streamgrid.net Fri Jan 11 17:56:53 2013 From: latifer at streamgrid.net (Latif Khalifa) Date: Sat, 12 Jan 2013 02:56:53 +0100 Subject: [opensource-dev] Upcoming server side avatar baking In-Reply-To: <20130111211316.5909ad48.sldev@free.fr> References: <50CB9CEA.3000509@lindenlab.com> <20130109172651.533611be.sldev@free.fr> <20130111211316.5909ad48.sldev@free.fr> Message-ID: On Fri, Jan 11, 2013 at 9:13 PM, Henri Beauchamp wrote: > Nevermind (though, having a propely built Linux Sunshine-viewer would > still be a good thing), I figured out the bug (race condition between > links creation in COF and rebake requests). How do you work around that? When I was implementing this in Radegast it seemed that the service would respond to link creation request and it would still sometimes fail with COF mismatch as if the baking service didn't get the message. > The of the Cool VL Viewer v1.26.7.5 (experimental branch) has been > released today with server-side baking support. Great! From sldev at free.fr Sat Jan 12 01:34:53 2013 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 12 Jan 2013 10:34:53 +0100 Subject: [opensource-dev] Upcoming server side avatar baking In-Reply-To: References: <50CB9CEA.3000509@lindenlab.com> <20130109172651.533611be.sldev@free.fr> <20130111211316.5909ad48.sldev@free.fr> Message-ID: <20130112103453.ee6a4b2e.sldev@free.fr> On Sat, 12 Jan 2013 02:56:53 +0100, Latif Khalifa wrote: > On Fri, Jan 11, 2013 at 9:13 PM, Henri Beauchamp wrote: > > Nevermind (though, having a propely built Linux Sunshine-viewer would > > still be a good thing), I figured out the bug (race condition between > > links creation in COF and rebake requests). > > How do you work around that? When I was implementing this in Radegast > it seemed that the service would respond to link creation request and > it would still sometimes fail with COF mismatch as if the baking > service didn't get the message. Well, my COF implementation is entirely different from LL's... For example, it only uses 3 functions and one callback to sync the COF (and that's because I also implemented *optional* attachments links syncing; without the optional part, i.e. with systematic attachments syncing, it'd take only 2 functions and one callback) and entirely avoids LL's (ridiculously) convoluted code; so it's hard to describe in a message... But to avoid the race conditions, I also modified the requestServerAppearanceUpdate() function and its callback (RequestAgentUpdateAppearanceResponder) so that only one such callback is active at any time (i.e. if other rebake requests are done before the last rebake is completed (or failed), the requests are "queued" (or more exactly, a mNeedsServerSideRebake flag is set and tested for to fire a new rebake on completion of the ongoing one). I also use a timer (gUpdateCOFTimer) that is reset each time a new link is created and tested for before requestServerAppearanceUpdate() is called (the latter being called in one place only, based on the mNeedsServerSideRebake flag and on the timer value). You'd better have a look at my code (at the end of llappearance.cpp) for full understanding of how things work; note that I since found a bug in it: in requestServerAppearanceUpdate(), the test for RequestAgentUpdateAppearanceResponder::isActive() should be moved inside the "if (!responder_ptr.get())" block. The bug only affects rebakes when a request fails and is retried within the RequestAgentUpdateAppearanceResponder callback (which didn't seem to happen so far on Aditi, given the very low load on the server-side rebaker). Note that there seem to be a server-side race condition as well: sometimes, the rebake request succeeds (with matching COF versions) and the viewer does recieve the UUIDs for the baked textures, but when it attempts to fetch the corresponding textures too soon (with 150+ FPS in the testing sims, the delay between the request acknowlegment and the texture fetch that happens at next frame can indeed be very short) the texture fetch fails with a 404 error: if you retrieve it later from a browser using the failed cap, you however do get the corresponding texture, meaning that the rebaker replied "ok" to the request before the texture could be made available by the texture server... Henri. From jhwelch at gmail.com Tue Jan 15 14:05:41 2013 From: jhwelch at gmail.com (Jonathan Yap) Date: Tue, 15 Jan 2013 22:05:41 -0000 Subject: [opensource-dev] Review Request: STORM-1892 - Add Apply button to the edit content permission floater In-Reply-To: <20120623233421.23634.11750@domU-12-31-38-00-90-68.compute-1.internal> References: <20120623233421.23634.11750@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130115220541.11978.13009@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/587/ ----------------------------------------------------------- (Updated Jan. 15, 2013, 2:05 p.m.) Review request for Viewer. Changes ------- LL wanted the default permissions checkboxes to revert to their initial values when Cancel is clicked. Description ------- Add Apply button to the edit content permission floater, now called Adjust Content Permissions. Minor rewording of title and floater text for clarity and to avoid confusion with STORM-68 (As a Builder, I want that ability to set default permissions on creation of objects, clothing, scripts, notecards, etc.), which is in the pipeline. This addresses bug STORM-1892. https://jira.secondlife.com/browse/STORM-1892 Diffs (updated) ----- doc/contributions.txt 4d9106153407 indra/newview/llfloaterbulkpermission.h 4d9106153407 indra/newview/llfloaterbulkpermission.cpp 4d9106153407 indra/newview/skins/default/xui/en/floater_bulk_perms.xml 4d9106153407 Diff: http://codereview.secondlife.com/r/587/diff/ Testing ------- See test plan in jira Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130115/dcb04339/attachment.htm From oz at lindenlab.com Tue Jan 22 09:41:58 2013 From: oz at lindenlab.com (Oz Linden) Date: Tue, 22 Jan 2013 17:41:58 -0000 Subject: [opensource-dev] Review Request: OPEN-159 / Faster, nicer Depth of Field In-Reply-To: <20130111220046.2360.88609@domU-12-31-38-00-90-68.compute-1.internal> References: <20130111220046.2360.88609@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130122174158.25149.17944@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/615/#review1298 ----------------------------------------------------------- See problem report in Jira at https://jira.secondlife.com/browse/STORM-1927?focusedCommentId=362619&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-362619 - Oz Linden On Jan. 11, 2013, 2 p.m., Tofu Buzzard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/615/ > ----------------------------------------------------------- > > (Updated Jan. 11, 2013, 2 p.m.) > > > Review request for Viewer. > > > Description > ------- > > This turns on bilinear filtering of the composited screen buffer used as the colour source for the depth-of-field effect (and its downscaled version). > This simply means that we can get away with around half as many samples for the same quality of bokeh effect. The samples we do take express the desired radius more accurately too, so there aren't such glaring delineations in blurredness. > > To celebrate being about twice as fast, I've also upped the maximum fatness of the bokeh effect for situations of extreme defocus. So typical cases are around twice as fast, and the extreme bokeh situation is around the previous speed but with fatter highlights. > > > This addresses bug OPEN-159. > http://jira.secondlife.com/browse/OPEN-159 > > > Diffs > ----- > > indra/llrender/llpostprocess.cpp UNKNOWN > indra/newview/app_settings/settings.xml UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/postDeferredF.glsl UNKNOWN > indra/newview/pipeline.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/615/diff/ > > > Testing > ------- > > Been running like this for a while myself... > > > Thanks, > > Tofu Buzzard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130122/38d5ead1/attachment.htm From oz at lindenlab.com Tue Jan 29 08:54:22 2013 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 29 Jan 2013 11:54:22 -0500 Subject: [opensource-dev] Increased maximum animation length Message-ID: <5107FEBE.7070807@lindenlab.com> A change coming in the 3.4.5 Beta that other viewers will probably want to adopt quickly.... Increase maximum animation length from 30 seconds to 60 seconds -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130129/f04d360c/attachment.htm From tillie at xp2.de Wed Jan 30 04:22:42 2013 From: tillie at xp2.de (Tillie Ariantho) Date: Wed, 30 Jan 2013 13:22:42 +0100 Subject: [opensource-dev] LSL commands/parameters for light projectors Message-ID: <51091092.4050903@xp2.de> Hello, my feature request BUG-1497 (see below) got closed (not applicable). Why that? Do we have so submit working patches for features requests? I think my request is pretty valid. *LSL commands for light projectors* Implementation of additional LSL command parameters: I would add parameters for llSetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast: Flag: PRIM_CAST_LIGHT Description: Let the prim with activated point light cast shadows. Usage: [ PRIM_CAST_LIGHT, key projection_texture, integer fov, integer focus, integer ambiance ] Texture, FOV, Focus and Ambiance are already properties of a prim, only they cannot get accessed via scripts yet. Why can't we set those parameters via scripts? Tillie