From Lance.Corrimal at eregion.de Fri Mar 2 01:45:01 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 02 Mar 2012 09:45:01 -0000 Subject: [opensource-dev] Review Request: Implement Qarls Aligning tool into Tools floater In-Reply-To: <20120302083007.14776.57203@domU-12-31-38-00-90-68.compute-1.internal> References: <20120302083007.14776.57203@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120302094501.14779.68079@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/543/#review1170 ----------------------------------------------------------- Ship it! Testing done: this tool has been in dolphin viewer for over a year now, to great benefit of the users, and has shown no problems. - Lance Corrimal On March 2, 2012, 12:30 a.m., Tobias Roth wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/543/ > ----------------------------------------------------------- > > (Updated March 2, 2012, 12:30 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Qarls Aligning tool ported over from Nirans Viewer for code review > > > Diffs > ----- > > indra/newview/llfloatertools.cpp b91d07f8fad9 > indra/newview/qtoolalign.h PRE-CREATION > indra/newview/qtoolalign.cpp PRE-CREATION > indra/newview/skins/default/xui/de/floater_tools.xml b91d07f8fad9 > indra/newview/skins/default/xui/en/floater_tools.xml b91d07f8fad9 > > Diff: http://codereview.secondlife.com/r/543/diff/diff > > > Testing > ------- > > > Thanks, > > Tobias Roth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120302/4f007ed1/attachment.htm From liny.odell at phoenixviewer.com Fri Mar 2 10:36:25 2012 From: liny.odell at phoenixviewer.com (Liny Odell) Date: Fri, 2 Mar 2012 10:36:25 -0800 Subject: [opensource-dev] Review Request: Implement Qarls Aligning tool into Tools floater In-Reply-To: <20120302094501.14779.68079@domU-12-31-38-00-90-68.compute-1.internal> References: <20120302083007.14776.57203@domU-12-31-38-00-90-68.compute-1.internal> <20120302094501.14779.68079@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: Please see https://jira.secondlife.com/browse/STORM-468 On Fri, Mar 2, 2012 at 1:45 AM, Lance Corrimal wrote: > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/543/ > > Ship it! > > Testing done: this tool has been in dolphin viewer for over a year now, to great benefit of the users, and has shown no problems. > > > - Lance > > On March 2nd, 2012, 12:30 a.m., Tobias Roth wrote: > Review request for Viewer. > By Tobias Roth. > > *Updated March 2, 2012, 12:30 a.m.* > Description > > Qarls Aligning tool ported over from Nirans Viewer for code review > > Diffs > > - indra/newview/llfloatertools.cpp (b91d07f8fad9) > - indra/newview/qtoolalign.h (PRE-CREATION) > - indra/newview/qtoolalign.cpp (PRE-CREATION) > - indra/newview/skins/default/xui/de/floater_tools.xml (b91d07f8fad9) > - indra/newview/skins/default/xui/en/floater_tools.xml (b91d07f8fad9) > > View Diff > > _______________________________________________ > 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/20120302/a5ce75a2/attachment.htm From nickyperian at yahoo.com Fri Mar 2 10:46:20 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Fri, 02 Mar 2012 18:46:20 -0000 Subject: [opensource-dev] Review Request: Implement Qarls Aligning tool into Tools floater In-Reply-To: <20120302083007.14776.57203@domU-12-31-38-00-90-68.compute-1.internal> References: <20120302083007.14776.57203@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120302184620.14773.83228@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/543/#review1171 ----------------------------------------------------------- Do qtoolsalign.cpp aand qtoolsalign.h need to added to /indra/newview/CMakeLists.txt? - Nicky Perian On March 2, 2012, 12:30 a.m., Tobias Roth wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/543/ > ----------------------------------------------------------- > > (Updated March 2, 2012, 12:30 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Qarls Aligning tool ported over from Nirans Viewer for code review > > > Diffs > ----- > > indra/newview/llfloatertools.cpp b91d07f8fad9 > indra/newview/qtoolalign.h PRE-CREATION > indra/newview/qtoolalign.cpp PRE-CREATION > indra/newview/skins/default/xui/de/floater_tools.xml b91d07f8fad9 > indra/newview/skins/default/xui/en/floater_tools.xml b91d07f8fad9 > > Diff: http://codereview.secondlife.com/r/543/diff/diff > > > Testing > ------- > > > Thanks, > > Tobias Roth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120302/bd24aadb/attachment.htm From Lance.Corrimal at eregion.de Fri Mar 2 10:48:02 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 02 Mar 2012 19:48:02 +0100 Subject: [opensource-dev] Review Request: Implement Qarls Aligning tool into Tools floater In-Reply-To: References: <20120302083007.14776.57203@domU-12-31-38-00-90-68.compute-1.internal> <20120302094501.14779.68079@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <3144797.kZnGrG12MH@sai> You do know that that jira links to this CR request, right? bye, LC Am Freitag, 2. M?rz 2012, 10:36:25 schrieb Liny Odell: > Please see https://jira.secondlife.com/browse/STORM-468 > > On Fri, Mar 2, 2012 at 1:45 AM, Lance Corrimal wrote: > > This is an automatically generated e-mail. To reply, visit: > > http://codereview.secondlife.com/r/543/ > > > > Ship it! > > > > Testing done: this tool has been in dolphin viewer for over a year now, to > > great benefit of the users, and has shown no problems. > > > > > > - Lance > > > > On March 2nd, 2012, 12:30 a.m., Tobias Roth wrote: > > Review request for Viewer. > > > > By Tobias Roth. > > > > *Updated March 2, 2012, 12:30 a.m.* > > Description > > > > Qarls Aligning tool ported over from Nirans Viewer for code review > > > > Diffs > > > > - indra/newview/llfloatertools.cpp (b91d07f8fad9) > > - indra/newview/qtoolalign.h (PRE-CREATION) > > - indra/newview/qtoolalign.cpp (PRE-CREATION) > > - indra/newview/skins/default/xui/de/floater_tools.xml (b91d07f8fad9) > > - indra/newview/skins/default/xui/en/floater_tools.xml (b91d07f8fad9) > > > > View Diff > > > > _______________________________________________ > > 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 From jaeger_Reg at hotmail.com Fri Mar 2 11:02:55 2012 From: jaeger_Reg at hotmail.com (Tankmaster Finesmith) Date: Fri, 02 Mar 2012 19:02:55 -0000 Subject: [opensource-dev] Review Request: Implement Qarls Aligning tool into Tools floater In-Reply-To: <20120302083007.14776.57203@domU-12-31-38-00-90-68.compute-1.internal> References: <20120302083007.14776.57203@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120302190255.14778.14214@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/543/#review1172 ----------------------------------------------------------- I would suggest using "size *= 1.25;" instead of "size *= 2.0;" to better conform with existing hover over edit arrows behavior (normal edit arrows). This is what we use in Firestorm currently. This is in qtoolalign.cpp line 330 - Tankmaster Finesmith On March 2, 2012, 12:30 a.m., Tobias Roth wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/543/ > ----------------------------------------------------------- > > (Updated March 2, 2012, 12:30 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Qarls Aligning tool ported over from Nirans Viewer for code review > > > Diffs > ----- > > indra/newview/llfloatertools.cpp b91d07f8fad9 > indra/newview/qtoolalign.h PRE-CREATION > indra/newview/qtoolalign.cpp PRE-CREATION > indra/newview/skins/default/xui/de/floater_tools.xml b91d07f8fad9 > indra/newview/skins/default/xui/en/floater_tools.xml b91d07f8fad9 > > Diff: http://codereview.secondlife.com/r/543/diff/diff > > > Testing > ------- > > > Thanks, > > Tobias Roth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120302/aa92ec9a/attachment-0001.htm From nickyperian at yahoo.com Fri Mar 2 11:13:42 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Fri, 02 Mar 2012 19:13:42 -0000 Subject: [opensource-dev] Review Request: Implement Qarls Aligning tool into Tools floater In-Reply-To: <20120302083007.14776.57203@domU-12-31-38-00-90-68.compute-1.internal> References: <20120302083007.14776.57203@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120302191342.14773.62405@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/543/#review1173 ----------------------------------------------------------- qtoolalign not qtools - Nicky Perian On March 2, 2012, 12:30 a.m., Tobias Roth wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/543/ > ----------------------------------------------------------- > > (Updated March 2, 2012, 12:30 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Qarls Aligning tool ported over from Nirans Viewer for code review > > > Diffs > ----- > > indra/newview/llfloatertools.cpp b91d07f8fad9 > indra/newview/qtoolalign.h PRE-CREATION > indra/newview/qtoolalign.cpp PRE-CREATION > indra/newview/skins/default/xui/de/floater_tools.xml b91d07f8fad9 > indra/newview/skins/default/xui/en/floater_tools.xml b91d07f8fad9 > > Diff: http://codereview.secondlife.com/r/543/diff/diff > > > Testing > ------- > > > Thanks, > > Tobias Roth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120302/5e9a9151/attachment.htm From liny.odell at phoenixviewer.com Fri Mar 2 11:22:03 2012 From: liny.odell at phoenixviewer.com (Liny Odell) Date: Fri, 2 Mar 2012 11:22:03 -0800 Subject: [opensource-dev] Review Request: Implement Qarls Aligning tool into Tools floater In-Reply-To: <3144797.kZnGrG12MH@sai> References: <20120302083007.14776.57203@domU-12-31-38-00-90-68.compute-1.internal> <20120302094501.14779.68079@domU-12-31-38-00-90-68.compute-1.internal> <3144797.kZnGrG12MH@sai> Message-ID: Yea, I noticed that as read more into the comments on that jira, but it may be useful for others to have a link in both directions (into and out of the code review) On Fri, Mar 2, 2012 at 10:48 AM, Lance Corrimal wrote: > You do know that that jira links to this CR request, right? > > > bye, > LC > > Am Freitag, 2. M?rz 2012, 10:36:25 schrieb Liny Odell: >> Please see https://jira.secondlife.com/browse/STORM-468 >> >> On Fri, Mar 2, 2012 at 1:45 AM, Lance Corrimal > wrote: >> > ? ?This is an automatically generated e-mail. To reply, visit: >> > http://codereview.secondlife.com/r/543/ >> > >> > Ship it! >> > >> > Testing done: this tool has been in dolphin viewer for over a year now, to >> > great benefit of the users, and has shown no problems. >> > >> > >> > - Lance >> > >> > On March 2nd, 2012, 12:30 a.m., Tobias Roth wrote: >> > ? Review request for Viewer. >> > >> > By Tobias Roth. >> > >> > *Updated March 2, 2012, 12:30 a.m.* >> > Description >> > >> > Qarls Aligning tool ported over from Nirans Viewer for code review >> > >> > ? Diffs >> > >> > ? ?- indra/newview/llfloatertools.cpp (b91d07f8fad9) >> > ? ?- indra/newview/qtoolalign.h (PRE-CREATION) >> > ? ?- indra/newview/qtoolalign.cpp (PRE-CREATION) >> > ? ?- indra/newview/skins/default/xui/de/floater_tools.xml (b91d07f8fad9) >> > ? ?- indra/newview/skins/default/xui/en/floater_tools.xml (b91d07f8fad9) >> > >> > View Diff >> > >> > _______________________________________________ >> > 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 From fuerholz at gmx.net Tue Mar 6 22:27:00 2012 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Wed, 07 Mar 2012 06:27:00 -0000 Subject: [opensource-dev] Review Request: Fix for viewer crash when entering anything but a valid dns-address into the grid selection combo (login screen). Message-ID: <20120307062700.23916.27003@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/563/ ----------------------------------------------------------- Review request for Viewer. Description ------- FIX FOR VWR-23741 (https://jira.secondlife.com/browse/vwr-23741) "Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter." Repository with fix: https://bitbucket.org/MartinRJ/vwr-23741 About: When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error ("throw LLInvalidGridName(grid);"). This fix adds code to: notifications.xml (a warning message text/notification: "IllegalGridName"), llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). Todo: Maybe edit the notification message, and update the language files. This addresses bug VWR-23741. http://jira.secondlife.com/browse/VWR-23741 Diffs ----- indra/llcommon/llversionviewer.h e9c82fca5ae6 Diff: http://codereview.secondlife.com/r/563/diff/diff Testing ------- Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). Thanks, MartinRJ Fayray -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120307/7bf89a90/attachment.htm From fuerholz at gmx.net Tue Mar 6 22:31:31 2012 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Wed, 07 Mar 2012 06:31:31 -0000 Subject: [opensource-dev] Review Request: VWR-23741: Fix for viewer crash when entering anything but a valid dns-address into the grid selection combo (login screen). In-Reply-To: <20120307062700.23916.27003@domU-12-31-38-00-90-68.compute-1.internal> References: <20120307062700.23916.27003@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120307063131.23918.85492@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/563/ ----------------------------------------------------------- (Updated March 6, 2012, 10:31 p.m.) Review request for Viewer. Summary (updated) ----------------- VWR-23741: Fix for viewer crash when entering anything but a valid dns-address into the grid selection combo (login screen). Description ------- FIX FOR VWR-23741 (https://jira.secondlife.com/browse/vwr-23741) "Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter." Repository with fix: https://bitbucket.org/MartinRJ/vwr-23741 About: When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error ("throw LLInvalidGridName(grid);"). This fix adds code to: notifications.xml (a warning message text/notification: "IllegalGridName"), llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). Todo: Maybe edit the notification message, and update the language files. This addresses bug VWR-23741. http://jira.secondlife.com/browse/VWR-23741 Diffs ----- indra/llcommon/llversionviewer.h e9c82fca5ae6 Diff: http://codereview.secondlife.com/r/563/diff/diff Testing ------- Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). Thanks, MartinRJ Fayray -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120307/58de9f3c/attachment.htm From fuerholz at gmx.net Tue Mar 6 23:15:52 2012 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Wed, 07 Mar 2012 07:15:52 -0000 Subject: [opensource-dev] Review Request: VWR-23741: Fix for viewer crash when entering anything but a valid dns-address into the grid selection combo (login screen). In-Reply-To: <20120307063131.23918.85492@domU-12-31-38-00-90-68.compute-1.internal> References: <20120307063131.23918.85492@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120307071552.634.7046@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/563/ ----------------------------------------------------------- (Updated March 6, 2012, 11:15 p.m.) Review request for Viewer. Description ------- FIX FOR VWR-23741 (https://jira.secondlife.com/browse/vwr-23741) "Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter." Repository with fix: https://bitbucket.org/MartinRJ/vwr-23741 About: When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error ("throw LLInvalidGridName(grid);"). This fix adds code to: notifications.xml (a warning message text/notification: "IllegalGridName"), llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). Todo: Maybe edit the notification message, and update the language files. This addresses bug VWR-23741. http://jira.secondlife.com/browse/VWR-23741 Diffs (updated) ----- indra/newview/llpanellogin.cpp 0a41a8750048 indra/newview/llviewernetwork.h 0a41a8750048 indra/newview/skins/default/xui/en/notifications.xml 0a41a8750048 Diff: http://codereview.secondlife.com/r/563/diff/diff Testing ------- Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). Thanks, MartinRJ Fayray -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120307/beb59b50/attachment.htm From oz at lindenlab.com Wed Mar 7 12:05:13 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 07 Mar 2012 15:05:13 -0500 Subject: [opensource-dev] Hippotropolis Theater Design Competition Message-ID: <4F57BF79.40001@lindenlab.com> Hippotropolis is our region for promoting and supporting the open source program, and I've been doing some updating there; as part of that, Linden Lab is sponsoring a competition to design a new meeting space: https://wiki.secondlife.com/wiki/Hippotropolis_Theater_Design_Competition From bryon at slearth.com Wed Mar 7 19:57:29 2012 From: bryon at slearth.com (Bryon Ruxton) Date: Wed, 07 Mar 2012 19:57:29 -0800 Subject: [opensource-dev] Hippotropolis Theater Design Competition In-Reply-To: <4F57BF79.40001@lindenlab.com> Message-ID: Oh! The grand prize is a lunch? Such a grandiose generosity from Linden Lab!!! The losers get to sell their models on the marketplace instead for more L$... PS: Don't forget to flush the toilet Oz. On 3/7/12 12:05 PM, "Oz Linden (Scott Lawrence)" wrote: >Hippotropolis is our region for promoting and supporting the open source >program, and I've been doing some updating there; as part of that, >Linden Lab is sponsoring a competition to design a new meeting space: > >https://wiki.secondlife.com/wiki/Hippotropolis_Theater_Design_Competition > > >_______________________________________________ >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 From sythos at gmail.com Fri Mar 9 16:29:50 2012 From: sythos at gmail.com (Sythos) Date: Sat, 10 Mar 2012 01:29:50 +0100 Subject: [opensource-dev] Review Request: OPEN-125 Open source mesh upload using hacd. In-Reply-To: <20111119202616.28175.81323@domU-12-31-38-00-90-68.compute-1.internal> References: <20111119202616.28175.81323@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120310012950.2839dae1a609c465629691c0@gmail.com> On Sat, 19 Nov 2011 20:26:16 -0000 "Nicky Perian" wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/519/ > ----------------------------------------------------------- any news from other OS devs? From oz at lindenlab.com Sat Mar 10 08:58:08 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Sat, 10 Mar 2012 11:58:08 -0500 Subject: [opensource-dev] Change to repository usage - take note Message-ID: <4F5B8820.90706@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120310/0e46d97a/attachment.htm From aklo at skyhighway.com Sat Mar 10 15:34:54 2012 From: aklo at skyhighway.com (aklo at skyhighway.com) Date: Sat, 10 Mar 2012 15:34:54 -0800 Subject: [opensource-dev] Why Develop? Message-ID: Hey Everybody! pls forgive me if this sounds kinda off-topic. i don't think it is, really, but you have to be a little patient. Anyway, before you read the hopefully un-boring things i have to say, pls look at this: http://www.reuters.com/article/2012/03/09/us-japan-digital-diva-idUSBRE8280DO20120309?feedType=RSS&feedName=oddlyEnoughNews This: http://www.youtube.com/watch?v=R-8POAZLIes And this: http://www.youtube.com/watch?v=xBZOlipfjkQ (In that order - and don't forget to turn on subtitles in your player for the YouTube videos, unless you do Japanese, of course.) i've kinda given up on hanging out with ppl in SL because i don't really fit in. i still do SL, i just don't hang out with ppl. (Pls resist the urge to turn me off here, to make my point, i gotta explain where it comes from 1st.) One big diff is that i'm not a gamer. Actually, i *hate* gaming. To me, gaming is a kind of heroin, and the ppl who do it are kinda like junkies, no offense, pls, if you think i'm pointing at you. i couldn't say that if i didn't know what it's like. Being a junkie, i mean. Been there, done that, moved on. So, i'm not criticizing gamers, just explaining that i understand the trip in ways gamers maybe don't realize. The diff between gaming & what ppl like me get outta SL is that gaming misses a lot of the idea in enhanced reality. Enhanced reality is more than Hatsune Miko, it's also those robots cruisin around on Mars and stuff like that. SL has potential to be that, & more. Treating it like a game & developing it like just for gamers (& the phony romance/sex creeps - don't even get me started!) is practically a crime against humanity for being given a priceless gateway to making the most xtreme imagination real & then just polishing the gates' hinges or something instead of using it to go somewhere. (BTW, don't think i'm trying to make an idea like being Hatsune Miko in SL a goal. She's neat & all, but there's way more to it than that. She's just really good at getting attention. Serious. Remember what they said in the vids about her record sales? And after you remember that, think about how many millions - hundreds of millions - of ppl in the world would be into SL if it were more than a game, & oh yeah, not tryin to make a big deal out of "property rights" & IP & all that *junk*. What i'm on about is a step beyond.) One solid example - That's one reason why i don't understand why, after the several ppl i've seen here trying to get live action controls to move our avis, we still have the crude controls SL started with and what has often seemed like movement away from immersion instead of obsession on expanding it. i know there's a big diff between the kind of animation that makes Miko "real" & what's possible for great gobs of ppl not paying several Gs a month to access shared (not super) computers on the Internet. But there's still a lot that can be done. Some really good things have been happening in SL, & i think some of the devs here are totally as good as the PhDs at work where they basically let me be an admin. i'm just trying to get ppl to think about the kinda attitude that makes us able be the best selves our minds can imagine and maybe do something with it that changes more world than just SL, instead of just playing around sorta like inventing the Starship Enterprise just for the Holodeck & a cool ride to a concert or something. That's it! Sorry (again, like always) for the non-technical content. Like my boss & my fave teachers say, sometimes you have to get up to 40,000 feet to get a view of the world that's useful for you on the ground, crawling over big rocks to get where you're going. You're all way better at all of that than me. i just wanna help if i can. - AK From hitomi.tiponi at yahoo.co.uk Sun Mar 11 00:51:14 2012 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Sun, 11 Mar 2012 08:51:14 +0000 (GMT) Subject: [opensource-dev] Change to repository usage - take note In-Reply-To: References: Message-ID: <1331455874.973.YahooMailNeo@web171002.mail.ukl.yahoo.com> In the past some special projects have fed straight into viewer-beta - does this mean that all new project work will always hit viewer-development before viewer-beta? What happens with viewer-pre-beta and viewer-pre-release? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120311/36d6eb32/attachment.htm From oz at lindenlab.com Sun Mar 11 07:47:37 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Sun, 11 Mar 2012 10:47:37 -0400 Subject: [opensource-dev] Change to repository usage - take note In-Reply-To: <1331455874.973.YahooMailNeo@web171002.mail.ukl.yahoo.com> References: <1331455874.973.YahooMailNeo@web171002.mail.ukl.yahoo.com> Message-ID: <4F5CBB09.6060800@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120311/89c25db8/attachment.htm From nexiim at gmail.com Mon Mar 12 01:46:37 2012 From: nexiim at gmail.com (Nexii Malthus) Date: Mon, 12 Mar 2012 08:46:37 +0000 Subject: [opensource-dev] Why Develop? In-Reply-To: References: Message-ID: > > One big diff is that i'm not a gamer. Actually, i *hate* > gaming. To me, gaming is a kind of heroin, and the ppl who do it are > kinda like junkies, no offense, pls, if you think i'm pointing at you. i > couldn't say that if i didn't know what it's like. Being a junkie, i > mean. Been there, done that, moved on. So, i'm not criticizing gamers, > just explaining that i understand the trip in ways gamers maybe don't > realize. > Sorry, but I have to address this point, I do fully understand where your coming from though, let me explain... As a game developer, I have actually been aware of a divide in the games industry for a long while. Prominently, there's two types of games, those that are addictive and those that aren't. There's a lot of game developers out there like me who hate how there are others intentionally creating addictive games that exploit people financially and emotionally. Not everyone is bad though and there are developers who don't like what is happening to modern games and are trying to reverse the current trends. Not all games are designed to be like heroin and it is becoming obvious when one is designed to be like that. (Every MMO is built around to exploit the most out of the addiction mechanics, the only rare exception I am aware of was Planetside 1) SL won't go down that path unless they stop developing new things for making good games possible. Otherwise we will be stuck in the pre-2010 state of SL where making addict mechanics is the only thing you can really do to make a successful game in SL. Besides that, I do fully agree with the rest of your email, and there are many SL residents who share your view as well. Unfortunately it doesn't seem like SL will ever head in that direction and SL probably shouldn't, because with LL's mismanagement we wouldn't get anywhere. It's probably better for people to concentrate their efforts on an opensource alternative to SL. - Nexii Malthus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120312/fc0cddd2/attachment.htm From geenz at geenzo.com Wed Mar 21 08:35:51 2012 From: geenz at geenzo.com (Geenz Spad) Date: Wed, 21 Mar 2012 15:35:51 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity Message-ID: <20120321153551.19599.82149@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/565/ ----------------------------------------------------------- Review request for Viewer. Description ------- For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) Where n is the specular exponent. Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. Test plan can be found in the JIRA. Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp This addresses bug STORM-1823. http://jira.secondlife.com/browse/STORM-1823 Diffs ----- indra/newview/app_settings/settings.xml 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/settings.xml 51b2fd52e36aab8f670e0874e7e1472434ec4b4a doc/contributions.txt 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/llviewercontrol.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/pipeline.h 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/pipeline.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/pipeline.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/pipeline.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a Diff: http://codereview.secondlife.com/r/565/diff/diff Testing ------- * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance Thanks, Geenz Spad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120321/b9778796/attachment.htm From geenz at geenzo.com Wed Mar 21 10:42:31 2012 From: geenz at geenzo.com (Geenz Spad) Date: Wed, 21 Mar 2012 17:42:31 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120321153551.19599.82149@domU-12-31-38-00-90-68.compute-1.internal> References: <20120321153551.19599.82149@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120321174231.19597.2896@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/565/ ----------------------------------------------------------- (Updated March 21, 2012, 10:42 a.m.) Review request for Viewer. Changes ------- Added a link to the latest builds of these changes. Description ------- For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) Where n is the specular exponent. Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. Test plan can be found in the JIRA. Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp This addresses bug STORM-1823. http://jira.secondlife.com/browse/STORM-1823 Diffs ----- indra/newview/app_settings/settings.xml 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/settings.xml 51b2fd52e36aab8f670e0874e7e1472434ec4b4a doc/contributions.txt 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/llviewercontrol.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/pipeline.h 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/pipeline.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/pipeline.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a indra/newview/pipeline.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a Diff: http://codereview.secondlife.com/r/565/diff/diff Testing (updated) ------- * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html Thanks, Geenz Spad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120321/0e58d21e/attachment.htm From geenz at geenzo.com Wed Mar 21 13:01:21 2012 From: geenz at geenzo.com (Geenz Spad) Date: Wed, 21 Mar 2012 20:01:21 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120321174231.19597.2896@domU-12-31-38-00-90-68.compute-1.internal> References: <20120321174231.19597.2896@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120321200121.19598.83444@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/565/ ----------------------------------------------------------- (Updated March 21, 2012, 1:01 p.m.) Review request for Viewer. Changes ------- Updated the diff to generally be cleaner, consolidating all changes into a single diff. Description ------- For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) Where n is the specular exponent. Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. Test plan can be found in the JIRA. Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp This addresses bug STORM-1823. http://jira.secondlife.com/browse/STORM-1823 Diffs (updated) ----- doc/contributions.txt b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/settings.xml b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/pipeline.h b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 Diff: http://codereview.secondlife.com/r/565/diff/diff Testing ------- * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html Thanks, Geenz Spad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120321/fad5f4a0/attachment.htm From secret.argent at gmail.com Thu Mar 22 01:57:57 2012 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 22 Mar 2012 03:57:57 -0500 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120321174231.19597.2896@domU-12-31-38-00-90-68.compute-1.internal> References: <20120321153551.19599.82149@domU-12-31-38-00-90-68.compute-1.internal> <20120321174231.19597.2896@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <8D3D69C5-AF5D-4BE1-BF72-C59DB8D1D8FA@gmail.com> On 2012-03-21, at 12:42, Geenz Spad wrote: > > For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. Could we see some examples of SL scenes using the two models, because there have been a number of changes to the SL renderer over the years... and the main effect of increasing the "realism" of the renderer has been to throw the deficiencies of the SL avatar mesh into sharp relief. The current specular model was a deliberate compromise. From oz at lindenlab.com Fri Mar 23 06:25:19 2012 From: oz at lindenlab.com (Oz Linden) Date: Fri, 23 Mar 2012 13:25:19 -0000 Subject: [opensource-dev] Review Request: STORM-1812 Music stream does not always restart after teleporting In-Reply-To: <20120215131244.25286.60366@domU-12-31-38-00-90-68.compute-1.internal> References: <20120215131244.25286.60366@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120323132519.20393.20976@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/556/#review1175 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Feb. 15, 2012, 5:12 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/556/ > ----------------------------------------------------------- > > (Updated Feb. 15, 2012, 5:12 a.m.) > > > Review request for Viewer. > > > Description > ------- > > The music stream does not restart if you teleport within the same parcel. > > > This addresses bug STORM-1812. > http://jira.secondlife.com/browse/STORM-1812 > > > Diffs > ----- > > doc/contributions.txt 0a41a8750048 > indra/newview/llvieweraudio.h 0a41a8750048 > indra/newview/llvieweraudio.cpp 0a41a8750048 > indra/newview/llviewerparcelmgr.h 0a41a8750048 > indra/newview/llviewerparcelmgr.cpp 0a41a8750048 > > Diff: http://codereview.secondlife.com/r/556/diff/diff > > > Testing > ------- > > See Test Plan in jira. > > During early investigation and testing of this fix there were times the play button became grayed out. I have not been able to reproduce this condition recently. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120323/a154ebb9/attachment.htm From oz at lindenlab.com Fri Mar 23 06:26:18 2012 From: oz at lindenlab.com (Oz Linden) Date: Fri, 23 Mar 2012 13:26:18 -0000 Subject: [opensource-dev] Review Request: VWR-28087: When I upload a texture, the "preview as" dropdown in the preview window is hidden under the texture In-Reply-To: <20120112100600.13488.90029@domU-12-31-38-00-90-68.compute-1.internal> References: <20120112100600.13488.90029@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120323132618.26864.84976@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/532/#review1176 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Jan. 12, 2012, 2:06 a.m., Lance Corrimal wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/532/ > ----------------------------------------------------------- > > (Updated Jan. 12, 2012, 2:06 a.m.) > > > Review request for Viewer. > > > Description > ------- > > At some point in the last 8 months the height of image previews in the upload preview floater was increased by 20, without adapting the actual floater, leading to VWR-28087. > This small patch fixes that by adapting the preview floater to the new height. > > > This addresses bug VWR-28087. > http://jira.secondlife.com/browse/VWR-28087 > > > Diffs > ----- > > indra/newview/skins/default/xui/en/floater_image_preview.xml 4982ab91ef6a > > Diff: http://codereview.secondlife.com/r/532/diff/diff > > > Testing > ------- > > tested with release viewer 3.2.5 and my own TPV, works fine. > > > Thanks, > > Lance Corrimal > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120323/37dbc991/attachment.htm From serpentu at gmail.com Fri Mar 23 09:01:02 2012 From: serpentu at gmail.com (Vaalith Jinn) Date: Fri, 23 Mar 2012 16:01:02 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 3.0 implementation. Message-ID: <20120323160102.19601.90176@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/566/ ----------------------------------------------------------- Review request for Viewer. Description ------- Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). *** DO NOT USE THIS YET *** do not implement for live viewers until fully reviewed. This addresses bug STORM-64. http://jira.secondlife.com/browse/STORM-64 Diffs ----- doc/contributions.txt 96a53bafcd1c indra/newview/CMakeLists.txt 96a53bafcd1c indra/newview/lllocalbitmaps.h PRE-CREATION indra/newview/lllocalbitmaps.cpp PRE-CREATION indra/newview/lltexturectrl.h 96a53bafcd1c indra/newview/lltexturectrl.cpp 96a53bafcd1c indra/newview/llviewertexturelist.h 96a53bafcd1c indra/newview/llwearable.h 96a53bafcd1c indra/newview/llwearable.cpp 96a53bafcd1c indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 96a53bafcd1c Diff: http://codereview.secondlife.com/r/566/diff/diff Testing ------- Thanks, Vaalith Jinn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120323/b3d257b8/attachment.htm From fuerholz at gmx.net Sat Mar 24 05:33:09 2012 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Sat, 24 Mar 2012 12:33:09 -0000 Subject: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo. In-Reply-To: <20120307071552.634.7046@domU-12-31-38-00-90-68.compute-1.internal> References: <20120307071552.634.7046@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120324123309.19598.34747@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/563/ ----------------------------------------------------------- (Updated March 24, 2012, 5:33 a.m.) Review request for Viewer. Changes ------- Rebuilt as STORM-1818 with repository pulled from viewer-release (updated diff-file). Summary (updated) ----------------- STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo. Description (updated) ------- FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) "Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter." Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ About: When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error ("throw LLInvalidGridName(grid);"). This fix adds code to: notifications.xml (a warning message text/notification: "IllegalGridName"), llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). Todo: Maybe edit the notification message, and update the language files. This addresses bug STORM-1818. http://jira.secondlife.com/browse/STORM-1818 Diffs (updated) ----- indra/newview/llpanellogin.cpp acfb0781d850 indra/newview/llviewernetwork.h acfb0781d850 indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 Diff: http://codereview.secondlife.com/r/563/diff/diff Testing ------- Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). Thanks, MartinRJ Fayray -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120324/d5e90ed2/attachment.htm From jhwelch at gmail.com Sat Mar 24 07:22:49 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Sat, 24 Mar 2012 14:22:49 -0000 Subject: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo. In-Reply-To: <20120324123309.19598.34747@domU-12-31-38-00-90-68.compute-1.internal> References: <20120324123309.19598.34747@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120324142249.23788.46513@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/563/#review1177 ----------------------------------------------------------- It seems to me that the better fix would be to support the URLs, as you say some TPVs do, that are currently causing trouble. - Jonathan Yap On March 24, 2012, 5:33 a.m., MartinRJ Fayray wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/563/ > ----------------------------------------------------------- > > (Updated March 24, 2012, 5:33 a.m.) > > > Review request for Viewer. > > > Description > ------- > > FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) "Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter." > > Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ > > About: > When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error ("throw LLInvalidGridName(grid);"). > > This fix adds code to: > notifications.xml (a warning message text/notification: "IllegalGridName"), > llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), > llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). > > Todo: Maybe edit the notification message, and update the language files. > > > This addresses bug STORM-1818. > http://jira.secondlife.com/browse/STORM-1818 > > > Diffs > ----- > > indra/newview/llpanellogin.cpp acfb0781d850 > indra/newview/llviewernetwork.h acfb0781d850 > indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 > > Diff: http://codereview.secondlife.com/r/563/diff/diff > > > Testing > ------- > > Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. > Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). > > > Thanks, > > MartinRJ Fayray > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120324/4ad11eb4/attachment.htm From fuerholz at gmx.net Sat Mar 24 07:58:23 2012 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Sat, 24 Mar 2012 14:58:23 -0000 Subject: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo. In-Reply-To: <20120324142249.23788.46513@domU-12-31-38-00-90-68.compute-1.internal> References: <20120324142249.23788.46513@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120324145823.19598.10153@domU-12-31-38-00-90-68.compute-1.internal> > On March 24, 2012, 7:22 a.m., Jonathan Yap wrote: > > It seems to me that the better fix would be to support the URLs, as you say some TPVs do, that are currently causing trouble. You can still login to non-Linden Lab grids via the --login URI parameter https://wiki.secondlife.com/wiki/Viewer_parameters But the grid selection combo doesn't support adding custom grids with a 'corrupt' format at all, as it seems the whole viewer is NOT designed for non-Linden Lab grids, see here: https://jira.secondlife.com/browse/VWR-28570?focusedCommentId=315423&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-315423 The hack to support these non-Linden Lab grid-format-urls as suggested here is an attempt to try parsing input data of any given format - be it valid or not - and a guessing game what the users input might mean, and that's in my honest opinion more of a 'political' question for the Linden Lab managment, and not a crash-fix-issue: https://jira.secondlife.com/browse/STORM-1818?focusedCommentId=314515&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-314515 Please test the fix/ship it. Thanks in advance. Kind regards, MartinRJ - MartinRJ ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/563/#review1177 ----------------------------------------------------------- On March 24, 2012, 5:33 a.m., MartinRJ Fayray wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/563/ > ----------------------------------------------------------- > > (Updated March 24, 2012, 5:33 a.m.) > > > Review request for Viewer. > > > Description > ------- > > FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) "Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter." > > Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ > > About: > When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error ("throw LLInvalidGridName(grid);"). > > This fix adds code to: > notifications.xml (a warning message text/notification: "IllegalGridName"), > llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), > llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). > > Todo: Maybe edit the notification message, and update the language files. > > > This addresses bug STORM-1818. > http://jira.secondlife.com/browse/STORM-1818 > > > Diffs > ----- > > indra/newview/llpanellogin.cpp acfb0781d850 > indra/newview/llviewernetwork.h acfb0781d850 > indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 > > Diff: http://codereview.secondlife.com/r/563/diff/diff > > > Testing > ------- > > Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. > Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). > > > Thanks, > > MartinRJ Fayray > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120324/4f61e842/attachment-0001.htm From Lance.Corrimal at eregion.de Sat Mar 24 08:08:15 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 24 Mar 2012 15:08:15 -0000 Subject: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo. In-Reply-To: <20120324123309.19598.34747@domU-12-31-38-00-90-68.compute-1.internal> References: <20120324123309.19598.34747@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120324150815.19601.23426@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/563/#review1179 ----------------------------------------------------------- I would like to point out that having all those linden-internal grids in there is utterly useless unless you are inside the linden lab network. How about adding a proper grid manager that supports actually accessible grids instead? - Lance Corrimal On March 24, 2012, 5:33 a.m., MartinRJ Fayray wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/563/ > ----------------------------------------------------------- > > (Updated March 24, 2012, 5:33 a.m.) > > > Review request for Viewer. > > > Description > ------- > > FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) "Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter." > > Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ > > About: > When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error ("throw LLInvalidGridName(grid);"). > > This fix adds code to: > notifications.xml (a warning message text/notification: "IllegalGridName"), > llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), > llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). > > Todo: Maybe edit the notification message, and update the language files. > > > This addresses bug STORM-1818. > http://jira.secondlife.com/browse/STORM-1818 > > > Diffs > ----- > > indra/newview/llpanellogin.cpp acfb0781d850 > indra/newview/llviewernetwork.h acfb0781d850 > indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 > > Diff: http://codereview.secondlife.com/r/563/diff/diff > > > Testing > ------- > > Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. > Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). > > > Thanks, > > MartinRJ Fayray > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120324/4f773a90/attachment.htm From fuerholz at gmx.net Sat Mar 24 09:36:05 2012 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Sat, 24 Mar 2012 16:36:05 -0000 Subject: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo. In-Reply-To: <20120324150815.19601.23426@domU-12-31-38-00-90-68.compute-1.internal> References: <20120324150815.19601.23426@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120324163605.19601.85869@domU-12-31-38-00-90-68.compute-1.internal> > On March 24, 2012, 8:08 a.m., Lance Corrimal wrote: > > I would like to point out that having all those linden-internal grids in there is utterly useless unless you are inside the linden lab network. How about adding a proper grid manager that supports actually accessible grids instead? @Lance this is only a review of my crash fix, no public discussion. It is only about this severe bug (abnormal program termination). This is not a public user group meeting where we discuss features, please bear in mind that you just demanded me - a volunteer contributor - to add a proper grid manager: "How about adding a proper grid manager"? The answer is: no! Of course not! - MartinRJ ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/563/#review1179 ----------------------------------------------------------- On March 24, 2012, 5:33 a.m., MartinRJ Fayray wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/563/ > ----------------------------------------------------------- > > (Updated March 24, 2012, 5:33 a.m.) > > > Review request for Viewer. > > > Description > ------- > > FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) "Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter." > > Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ > > About: > When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error ("throw LLInvalidGridName(grid);"). > > This fix adds code to: > notifications.xml (a warning message text/notification: "IllegalGridName"), > llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), > llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). > > Todo: Maybe edit the notification message, and update the language files. > > > This addresses bug STORM-1818. > http://jira.secondlife.com/browse/STORM-1818 > > > Diffs > ----- > > indra/newview/llpanellogin.cpp acfb0781d850 > indra/newview/llviewernetwork.h acfb0781d850 > indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 > > Diff: http://codereview.secondlife.com/r/563/diff/diff > > > Testing > ------- > > Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. > Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). > > > Thanks, > > MartinRJ Fayray > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120324/2f2f31cd/attachment.htm From Lance.Corrimal at eregion.de Sat Mar 24 11:20:13 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 24 Mar 2012 18:20:13 -0000 Subject: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo. In-Reply-To: <20120324150815.19601.23426@domU-12-31-38-00-90-68.compute-1.internal> References: <20120324150815.19601.23426@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120324182013.19595.26287@domU-12-31-38-00-90-68.compute-1.internal> > On March 24, 2012, 8:08 a.m., Lance Corrimal wrote: > > I would like to point out that having all those linden-internal grids in there is utterly useless unless you are inside the linden lab network. How about adding a proper grid manager that supports actually accessible grids instead? > > MartinRJ Fayray wrote: > @Lance this is only a review of my crash fix, no public discussion. It is only about this severe bug (abnormal program termination). This is not a public user group meeting where we discuss features, please bear in mind that you just demanded me - a volunteer contributor - to add a proper grid manager: > "How about adding a proper grid manager"? > The answer is: no! Of course not! I didn't "demand" anything from you, I was just suggesting something. Calm down a bit. - Lance ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/563/#review1179 ----------------------------------------------------------- On March 24, 2012, 5:33 a.m., MartinRJ Fayray wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/563/ > ----------------------------------------------------------- > > (Updated March 24, 2012, 5:33 a.m.) > > > Review request for Viewer. > > > Description > ------- > > FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) "Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter." > > Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ > > About: > When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error ("throw LLInvalidGridName(grid);"). > > This fix adds code to: > notifications.xml (a warning message text/notification: "IllegalGridName"), > llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), > llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). > > Todo: Maybe edit the notification message, and update the language files. > > > This addresses bug STORM-1818. > http://jira.secondlife.com/browse/STORM-1818 > > > Diffs > ----- > > indra/newview/llpanellogin.cpp acfb0781d850 > indra/newview/llviewernetwork.h acfb0781d850 > indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 > > Diff: http://codereview.secondlife.com/r/563/diff/diff > > > Testing > ------- > > Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. > Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). > > > Thanks, > > MartinRJ Fayray > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120324/d0ae8bd4/attachment-0001.htm From cinder at cinderblocks.biz Sat Mar 24 11:29:17 2012 From: cinder at cinderblocks.biz (Cindy Chidester) Date: Sat, 24 Mar 2012 18:29:17 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120321200121.19598.83444@domU-12-31-38-00-90-68.compute-1.internal> References: <20120321200121.19598.83444@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120324182917.28094.43921@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/565/#review1182 ----------------------------------------------------------- Ship it! Been running with this patch for about two days with no negative effect. Performance is more or less the same with much improved visuals, exceptionally well in bright lit areas (where previously, the light would almost wash out my avatar in white light) - Cindy Chidester On March 21, 2012, 1:01 p.m., Geenz Spad wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/565/ > ----------------------------------------------------------- > > (Updated March 21, 2012, 1:01 p.m.) > > > Review request for Viewer. > > > Description > ------- > > For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. > > This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: > ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) > Where n is the specular exponent. > > Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. > > Test plan can be found in the JIRA. > Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp > > > This addresses bug STORM-1823. > http://jira.secondlife.com/browse/STORM-1823 > > > Diffs > ----- > > doc/contributions.txt b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/settings.xml b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/pipeline.h b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > > Diff: http://codereview.secondlife.com/r/565/diff/diff > > > Testing > ------- > > * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance > * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such > * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) > * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance > > You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html > > > Thanks, > > Geenz Spad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120324/fc547993/attachment.htm From c at yotes.com Sun Mar 25 02:55:50 2012 From: c at yotes.com (Tofu Buzzard) Date: Sun, 25 Mar 2012 09:55:50 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120321200121.19598.83444@domU-12-31-38-00-90-68.compute-1.internal> References: <20120321200121.19598.83444@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120325095550.4403.6270@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/565/#review1183 ----------------------------------------------------------- I'd like to see the mis-named handleReleaseLUTBufferChanged be called handleLUTBufferChanged, and ideally I'd like some comment (probably in the LUT creation) about why the results of lookups should be multiplied by 4 (to avoid saturation in the LUT?). Otherwise, I reckon this is great. - Tofu Buzzard On March 21, 2012, 1:01 p.m., Geenz Spad wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/565/ > ----------------------------------------------------------- > > (Updated March 21, 2012, 1:01 p.m.) > > > Review request for Viewer. > > > Description > ------- > > For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. > > This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: > ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) > Where n is the specular exponent. > > Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. > > Test plan can be found in the JIRA. > Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp > > > This addresses bug STORM-1823. > http://jira.secondlife.com/browse/STORM-1823 > > > Diffs > ----- > > doc/contributions.txt b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/settings.xml b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/pipeline.h b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > > Diff: http://codereview.secondlife.com/r/565/diff/diff > > > Testing > ------- > > * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance > * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such > * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) > * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance > > You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html > > > Thanks, > > Geenz Spad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120325/53db2e56/attachment.htm From c at yotes.com Sun Mar 25 03:13:08 2012 From: c at yotes.com (Tofu Buzzard) Date: Sun, 25 Mar 2012 10:13:08 -0000 Subject: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo. In-Reply-To: <20120324123309.19598.34747@domU-12-31-38-00-90-68.compute-1.internal> References: <20120324123309.19598.34747@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120325101308.4931.54548@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/563/#review1184 ----------------------------------------------------------- Thanks for looking at this issue, MartinRJ. The only thing that give me pause for thought is - if the crash is coming from an uncaught exception, the 'right' thing to do seems to be to catch the exception and show the notification you've created then, aborting the login. Any clear reason why this isn't the approach? Does pre-validation give a better user experience? Cheers. - Tofu Buzzard On March 24, 2012, 5:33 a.m., MartinRJ Fayray wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/563/ > ----------------------------------------------------------- > > (Updated March 24, 2012, 5:33 a.m.) > > > Review request for Viewer. > > > Description > ------- > > FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) "Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter." > > Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ > > About: > When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error ("throw LLInvalidGridName(grid);"). > > This fix adds code to: > notifications.xml (a warning message text/notification: "IllegalGridName"), > llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), > llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). > > Todo: Maybe edit the notification message, and update the language files. > > > This addresses bug STORM-1818. > http://jira.secondlife.com/browse/STORM-1818 > > > Diffs > ----- > > indra/newview/llpanellogin.cpp acfb0781d850 > indra/newview/llviewernetwork.h acfb0781d850 > indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 > > Diff: http://codereview.secondlife.com/r/563/diff/diff > > > Testing > ------- > > Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. > Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). > > > Thanks, > > MartinRJ Fayray > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120325/718459d2/attachment.htm From fuerholz at gmx.net Sun Mar 25 04:07:56 2012 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Sun, 25 Mar 2012 11:07:56 -0000 Subject: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo. In-Reply-To: <20120325101308.4931.54548@domU-12-31-38-00-90-68.compute-1.internal> References: <20120325101308.4931.54548@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120325110756.4402.58237@domU-12-31-38-00-90-68.compute-1.internal> > On March 25, 2012, 3:13 a.m., Tofu Buzzard wrote: > > Thanks for looking at this issue, MartinRJ. > > The only thing that give me pause for thought is - if the crash is coming from an uncaught exception, the 'right' thing to do seems to be to catch the exception and show the notification you've created then, aborting the login. Any clear reason why this isn't the approach? Does pre-validation give a better user experience? > > Cheers. > > @Tofu: you want to remove the un-supported input string from the combo-box and have a valid grid selected instead. Otherwise, if you'd do what you've mentioned what would be the 'right' thing, and only catch the exception, if the user presses Login after that notification he'd get the next error. - MartinRJ ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/563/#review1184 ----------------------------------------------------------- On March 24, 2012, 5:33 a.m., MartinRJ Fayray wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/563/ > ----------------------------------------------------------- > > (Updated March 24, 2012, 5:33 a.m.) > > > Review request for Viewer. > > > Description > ------- > > FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) "Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter." > > Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ > > About: > When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error ("throw LLInvalidGridName(grid);"). > > This fix adds code to: > notifications.xml (a warning message text/notification: "IllegalGridName"), > llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), > llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). > > Todo: Maybe edit the notification message, and update the language files. > > > This addresses bug STORM-1818. > http://jira.secondlife.com/browse/STORM-1818 > > > Diffs > ----- > > indra/newview/llpanellogin.cpp acfb0781d850 > indra/newview/llviewernetwork.h acfb0781d850 > indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 > > Diff: http://codereview.secondlife.com/r/563/diff/diff > > > Testing > ------- > > Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. > Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). > > > Thanks, > > MartinRJ Fayray > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120325/97d6499a/attachment-0001.htm From c at yotes.com Sun Mar 25 05:29:13 2012 From: c at yotes.com (Tofu Buzzard) Date: Sun, 25 Mar 2012 12:29:13 -0000 Subject: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo. In-Reply-To: <20120324123309.19598.34747@domU-12-31-38-00-90-68.compute-1.internal> References: <20120324123309.19598.34747@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120325122913.4400.33065@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/563/#review1186 ----------------------------------------------------------- If the downside of that is that the user doesn't know their grid is invalid until they try to login then I reckon that's fine, but I'll defer to others. - Tofu Buzzard On March 24, 2012, 5:33 a.m., MartinRJ Fayray wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/563/ > ----------------------------------------------------------- > > (Updated March 24, 2012, 5:33 a.m.) > > > Review request for Viewer. > > > Description > ------- > > FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) "Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter." > > Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ > > About: > When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error ("throw LLInvalidGridName(grid);"). > > This fix adds code to: > notifications.xml (a warning message text/notification: "IllegalGridName"), > llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), > llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). > > Todo: Maybe edit the notification message, and update the language files. > > > This addresses bug STORM-1818. > http://jira.secondlife.com/browse/STORM-1818 > > > Diffs > ----- > > indra/newview/llpanellogin.cpp acfb0781d850 > indra/newview/llviewernetwork.h acfb0781d850 > indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 > > Diff: http://codereview.secondlife.com/r/563/diff/diff > > > Testing > ------- > > Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. > Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). > > > Thanks, > > MartinRJ Fayray > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120325/6d0a1434/attachment.htm From fuerholz at gmx.net Sun Mar 25 05:57:58 2012 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Sun, 25 Mar 2012 12:57:58 -0000 Subject: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo. In-Reply-To: <20120325122913.4400.33065@domU-12-31-38-00-90-68.compute-1.internal> References: <20120325122913.4400.33065@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120325125758.4400.21114@domU-12-31-38-00-90-68.compute-1.internal> > On March 25, 2012, 5:29 a.m., Tofu Buzzard wrote: > > If the downside of that is that the user doesn't know their grid is invalid until they try to login then I reckon that's fine, but I'll defer to others. @Tofu the malformed grid-address is added PERMANENTLY to the grid-list IMMEDIATELY if you don't prevent this. - MartinRJ ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/563/#review1186 ----------------------------------------------------------- On March 24, 2012, 5:33 a.m., MartinRJ Fayray wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/563/ > ----------------------------------------------------------- > > (Updated March 24, 2012, 5:33 a.m.) > > > Review request for Viewer. > > > Description > ------- > > FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) "Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter." > > Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ > > About: > When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error ("throw LLInvalidGridName(grid);"). > > This fix adds code to: > notifications.xml (a warning message text/notification: "IllegalGridName"), > llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), > llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). > > Todo: Maybe edit the notification message, and update the language files. > > > This addresses bug STORM-1818. > http://jira.secondlife.com/browse/STORM-1818 > > > Diffs > ----- > > indra/newview/llpanellogin.cpp acfb0781d850 > indra/newview/llviewernetwork.h acfb0781d850 > indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 > > Diff: http://codereview.secondlife.com/r/563/diff/diff > > > Testing > ------- > > Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. > Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). > > > Thanks, > > MartinRJ Fayray > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120325/82a4c938/attachment.htm From c at yotes.com Sun Mar 25 09:04:47 2012 From: c at yotes.com (Tofu Buzzard) Date: Sun, 25 Mar 2012 16:04:47 -0000 Subject: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo. In-Reply-To: <20120324123309.19598.34747@domU-12-31-38-00-90-68.compute-1.internal> References: <20120324123309.19598.34747@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120325160447.4403.99497@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/563/#review1188 ----------------------------------------------------------- Ship it! Ah, that makes things much clearer. Yes, that would be lame. - Tofu Buzzard On March 24, 2012, 5:33 a.m., MartinRJ Fayray wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/563/ > ----------------------------------------------------------- > > (Updated March 24, 2012, 5:33 a.m.) > > > Review request for Viewer. > > > Description > ------- > > FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) "Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter." > > Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ > > About: > When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error ("throw LLInvalidGridName(grid);"). > > This fix adds code to: > notifications.xml (a warning message text/notification: "IllegalGridName"), > llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), > llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). > > Todo: Maybe edit the notification message, and update the language files. > > > This addresses bug STORM-1818. > http://jira.secondlife.com/browse/STORM-1818 > > > Diffs > ----- > > indra/newview/llpanellogin.cpp acfb0781d850 > indra/newview/llviewernetwork.h acfb0781d850 > indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 > > Diff: http://codereview.secondlife.com/r/563/diff/diff > > > Testing > ------- > > Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. > Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). > > > Thanks, > > MartinRJ Fayray > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120325/0c78763a/attachment.htm From oz at lindenlab.com Sun Mar 25 11:06:56 2012 From: oz at lindenlab.com (Oz Linden) Date: Sun, 25 Mar 2012 18:06:56 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120321200121.19598.83444@domU-12-31-38-00-90-68.compute-1.internal> References: <20120321200121.19598.83444@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120325180656.5384.73050@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/565/ ----------------------------------------------------------- (Updated March 25, 2012, 11:06 a.m.) Review request for Viewer and David Parks. Description ------- For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) Where n is the specular exponent. Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. Test plan can be found in the JIRA. Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp This addresses bug STORM-1823. http://jira.secondlife.com/browse/STORM-1823 Diffs ----- doc/contributions.txt b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/settings.xml b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/pipeline.h b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 Diff: http://codereview.secondlife.com/r/565/diff/diff Testing ------- * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html Thanks, Geenz Spad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120325/627ef205/attachment-0001.htm From oz at lindenlab.com Sun Mar 25 11:08:15 2012 From: oz at lindenlab.com (Oz Linden) Date: Sun, 25 Mar 2012 18:08:15 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120325095550.4403.6270@domU-12-31-38-00-90-68.compute-1.internal> References: <20120325095550.4403.6270@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120325180815.5952.43239@domU-12-31-38-00-90-68.compute-1.internal> > On March 25, 2012, 2:55 a.m., Tofu Buzzard wrote: > > I'd like to see the mis-named handleReleaseLUTBufferChanged be called handleLUTBufferChanged, and ideally I'd like some comment (probably in the LUT creation) about why the results of lookups should be multiplied by 4 (to avoid saturation in the LUT?). > > Otherwise, I reckon this is great. I concur with both of these comments, and have asked for a review from Dave. - Oz ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/565/#review1183 ----------------------------------------------------------- On March 25, 2012, 11:06 a.m., Geenz Spad wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/565/ > ----------------------------------------------------------- > > (Updated March 25, 2012, 11:06 a.m.) > > > Review request for Viewer and David Parks. > > > Description > ------- > > For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. > > This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: > ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) > Where n is the specular exponent. > > Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. > > Test plan can be found in the JIRA. > Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp > > > This addresses bug STORM-1823. > http://jira.secondlife.com/browse/STORM-1823 > > > Diffs > ----- > > doc/contributions.txt b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/settings.xml b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/pipeline.h b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > > Diff: http://codereview.secondlife.com/r/565/diff/diff > > > Testing > ------- > > * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance > * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such > * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) > * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance > > You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html > > > Thanks, > > Geenz Spad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120325/7ae9ae25/attachment.htm From geenz at geenzo.com Sun Mar 25 14:07:49 2012 From: geenz at geenzo.com (Geenz Spad) Date: Sun, 25 Mar 2012 21:07:49 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120325180656.5384.73050@domU-12-31-38-00-90-68.compute-1.internal> References: <20120325180656.5384.73050@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120325210749.4397.98410@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/565/ ----------------------------------------------------------- (Updated March 25, 2012, 2:07 p.m.) Review request for Viewer and David Parks. Changes ------- Added more information as to why we multiply in our shaders, and why we're scaling our results by (1.f / 6) in our LUT creation. Also renamed handleReleaseLUTBufferChanged to handleLUTBufferChanged, per Tofu's request. Description ------- For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) Where n is the specular exponent. Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. Test plan can be found in the JIRA. Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp This addresses bug STORM-1823. http://jira.secondlife.com/browse/STORM-1823 Diffs (updated) ----- indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 Diff: http://codereview.secondlife.com/r/565/diff/diff Testing ------- * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html Thanks, Geenz Spad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120325/f00a0b16/attachment.htm From geenz at geenzo.com Sun Mar 25 14:10:29 2012 From: geenz at geenzo.com (Geenz Spad) Date: Sun, 25 Mar 2012 21:10:29 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120325095550.4403.6270@domU-12-31-38-00-90-68.compute-1.internal> References: <20120325095550.4403.6270@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120325211029.4401.83759@domU-12-31-38-00-90-68.compute-1.internal> > On March 25, 2012, 2:55 a.m., Tofu Buzzard wrote: > > I'd like to see the mis-named handleReleaseLUTBufferChanged be called handleLUTBufferChanged, and ideally I'd like some comment (probably in the LUT creation) about why the results of lookups should be multiplied by 4 (to avoid saturation in the LUT?). > > Otherwise, I reckon this is great. > > Oz Linden wrote: > I concur with both of these comments, and have asked for a review from Dave. The reasoning for doing this is basically just as you said, to avoid saturation in the LUT since most energy conserving specular models tend to exceed a floating point range of 0 to 1, something that should be accounted for when storing the results in an R8 LUT. Granted, one could just use a floating point LUT instead, but driver support can be a bit spotty for R16F and R32F. However, storing in an R16F LUT is something to look into in the future regardless if only to reduce banding. Scaling by 6 allows us to get a bit more of a higher range (same scale used by RGBM encoding), though whether or not it's really necessary is something potentially worth investigating. - Geenz ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/565/#review1183 ----------------------------------------------------------- On March 25, 2012, 2:07 p.m., Geenz Spad wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/565/ > ----------------------------------------------------------- > > (Updated March 25, 2012, 2:07 p.m.) > > > Review request for Viewer and David Parks. > > > Description > ------- > > For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. > > This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: > ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) > Where n is the specular exponent. > > Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. > > Test plan can be found in the JIRA. > Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp > > > This addresses bug STORM-1823. > http://jira.secondlife.com/browse/STORM-1823 > > > Diffs > ----- > > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > > Diff: http://codereview.secondlife.com/r/565/diff/diff > > > Testing > ------- > > * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance > * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such > * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) > * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance > > You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html > > > Thanks, > > Geenz Spad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120325/86106241/attachment.htm From secret.argent at gmail.com Sun Mar 25 14:56:22 2012 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 25 Mar 2012 21:56:22 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120325210749.4397.98410@domU-12-31-38-00-90-68.compute-1.internal> References: <20120325210749.4397.98410@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120325215622.4399.28169@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/565/#review1191 ----------------------------------------------------------- Could we see some examples of SL scenes using the two models, particularly with avatars in them, because there have been a number of changes to the SL renderer over the years... and the main effect of increasing the "realism" of the renderer has been to throw the deficiencies of the SL avatar mesh into sharp relief. The current specular model was a deliberate compromise between the older even-toonier renderer and a more "realistic" model that made avatars look horrible. - Argent Stonecutter On March 25, 2012, 2:07 p.m., Geenz Spad wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/565/ > ----------------------------------------------------------- > > (Updated March 25, 2012, 2:07 p.m.) > > > Review request for Viewer and David Parks. > > > Description > ------- > > For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. > > This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: > ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) > Where n is the specular exponent. > > Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. > > Test plan can be found in the JIRA. > Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp > > > This addresses bug STORM-1823. > http://jira.secondlife.com/browse/STORM-1823 > > > Diffs > ----- > > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > > Diff: http://codereview.secondlife.com/r/565/diff/diff > > > Testing > ------- > > * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance > * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such > * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) > * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance > > You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html > > > Thanks, > > Geenz Spad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120325/aa24ca5d/attachment-0001.htm From geenz at geenzo.com Sun Mar 25 15:36:38 2012 From: geenz at geenzo.com (Geenz Spad) Date: Sun, 25 Mar 2012 22:36:38 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120325215622.4399.28169@domU-12-31-38-00-90-68.compute-1.internal> References: <20120325215622.4399.28169@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120325223638.5900.88201@domU-12-31-38-00-90-68.compute-1.internal> > On March 25, 2012, 2:56 p.m., Argent Stonecutter wrote: > > Could we see some examples of SL scenes using the two models, particularly with avatars in them, because there have been a number of changes to the SL renderer over the years... and the main effect of increasing the "realism" of the renderer has been to throw the deficiencies of the SL avatar mesh into sharp relief. The current specular model was a deliberate compromise between the older even-toonier renderer and a more "realistic" model that made avatars look horrible. Avatars are only ever effected if they're using attachments that make sure of the shiny attribute. The diffuse shading on avatars remains unaffected. I think the "compromise" you're thinking of is the environment map that typically gets applied in classic forward rendering, which was later re-added to the deferred renderer to mitigate content breakage that resulted when it was removed, which hasn't been changed with my modifications. As I had mentioned previously, there are comparison pictures posted on the JIRA that everyone can see, and I would also very much appreciate it if people could post their own comparisons, and identify any in-world content breakage that relied on the previous model that was used. - Geenz ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/565/#review1191 ----------------------------------------------------------- On March 25, 2012, 2:07 p.m., Geenz Spad wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/565/ > ----------------------------------------------------------- > > (Updated March 25, 2012, 2:07 p.m.) > > > Review request for Viewer and David Parks. > > > Description > ------- > > For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. > > This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: > ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) > Where n is the specular exponent. > > Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. > > Test plan can be found in the JIRA. > Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp > > > This addresses bug STORM-1823. > http://jira.secondlife.com/browse/STORM-1823 > > > Diffs > ----- > > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > > Diff: http://codereview.secondlife.com/r/565/diff/diff > > > Testing > ------- > > * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance > * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such > * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) > * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance > > You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html > > > Thanks, > > Geenz Spad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120325/10dc95af/attachment.htm From c at yotes.com Sun Mar 25 15:39:54 2012 From: c at yotes.com (Tofu Buzzard) Date: Sun, 25 Mar 2012 22:39:54 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120325210749.4397.98410@domU-12-31-38-00-90-68.compute-1.internal> References: <20120325210749.4397.98410@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120325223954.4399.42199@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/565/#review1193 ----------------------------------------------------------- Ship it! 4 -> 6 is a bit of a last-minute change... :3 But ship it. - Tofu Buzzard On March 25, 2012, 2:07 p.m., Geenz Spad wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/565/ > ----------------------------------------------------------- > > (Updated March 25, 2012, 2:07 p.m.) > > > Review request for Viewer and David Parks. > > > Description > ------- > > For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. > > This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: > ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) > Where n is the specular exponent. > > Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. > > Test plan can be found in the JIRA. > Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp > > > This addresses bug STORM-1823. > http://jira.secondlife.com/browse/STORM-1823 > > > Diffs > ----- > > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > > Diff: http://codereview.secondlife.com/r/565/diff/diff > > > Testing > ------- > > * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance > * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such > * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) > * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance > > You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html > > > Thanks, > > Geenz Spad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120325/22364276/attachment.htm From geenz at geenzo.com Sun Mar 25 15:49:57 2012 From: geenz at geenzo.com (Geenz Spad) Date: Sun, 25 Mar 2012 22:49:57 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120325223954.4399.42199@domU-12-31-38-00-90-68.compute-1.internal> References: <20120325223954.4399.42199@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120325224957.4403.90367@domU-12-31-38-00-90-68.compute-1.internal> > On March 25, 2012, 3:39 p.m., Tofu Buzzard wrote: > > 4 -> 6 is a bit of a last-minute change... :3 But ship it. Mostly just using an idea I got from reading up on RGBM encoding, and why they scale by 6 as well (though really, in theory you could scale by pretty much any value so long as both the encode and decode use the same scales). Seems to work quite well, especially since medium shiny seems to have slightly less saturation induced artifacting. :3 - Geenz ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/565/#review1193 ----------------------------------------------------------- On March 25, 2012, 2:07 p.m., Geenz Spad wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/565/ > ----------------------------------------------------------- > > (Updated March 25, 2012, 2:07 p.m.) > > > Review request for Viewer and David Parks. > > > Description > ------- > > For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. > > This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: > ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) > Where n is the specular exponent. > > Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. > > Test plan can be found in the JIRA. > Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp > > > This addresses bug STORM-1823. > http://jira.secondlife.com/browse/STORM-1823 > > > Diffs > ----- > > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > > Diff: http://codereview.secondlife.com/r/565/diff/diff > > > Testing > ------- > > * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance > * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such > * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) > * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance > > You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html > > > Thanks, > > Geenz Spad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120325/acdf4cfd/attachment-0001.htm From flats_fixed at flatsfixedbicycles.com Sun Mar 25 20:56:55 2012 From: flats_fixed at flatsfixedbicycles.com (Flats Fixed) Date: Mon, 26 Mar 2012 11:56:55 +0800 Subject: [opensource-dev] tired of the bad testting Message-ID: the latest stable came out. it broke the teleporters at 2100 meters. you know guys this is not a jira this is simple testing. love the new policy but the fact is the team is running people out of SL. test it befor it goes stable. -- FLATS FIXED Emergency repairs flatsfixedbicycles.com This message has been sent by the most powerful bleeding edge operating system known to man SLACKWARE64-CURRENT We Get The Slack Back. It is free. Try it you will never go back just keep the slack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120326/1d96bade/attachment.htm From flats_fixed at flatsfixedbicycles.com Sun Mar 25 21:02:58 2012 From: flats_fixed at flatsfixedbicycles.com (Flats Fixed) Date: Mon, 26 Mar 2012 12:02:58 +0800 Subject: [opensource-dev] teleleport Message-ID: yes you can teleport that high. but not run a teleport script to come back. this is not jira. this is lack of testing. with the grid. same script to teleport you back will not work. simple test -- FLATS FIXED Emergency repairs flatsfixedbicycles.com This message has been sent by the most powerful bleeding edge operating system known to man SLACKWARE64-CURRENT We Get The Slack Back. It is free. Try it you will never go back just keep the slack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120326/df94d856/attachment.htm From Lance.Corrimal at eregion.de Mon Mar 26 00:22:52 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 26 Mar 2012 07:22:52 -0000 Subject: [opensource-dev] Review Request: Current viewer-development build does not build on linux Message-ID: <20120326072252.4396.68373@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/568/ ----------------------------------------------------------- Review request for Viewer. Description ------- The current viewer-development tree does not compile cleanly on linux (at least not on my openSUSE 12.1 and openSUSE 11.4 systems). This addresses bug VWR-28535. http://jira.secondlife.com/browse/VWR-28535 Diffs ----- indra/llmath/llcoord.h 6943d3e9deb7 Diff: http://codereview.secondlife.com/r/568/diff/diff Testing ------- patched viewer-development 3.3.1 and viewer-release 3.3.0, builds fine, usage test shows no ill effects Thanks, Lance Corrimal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120326/3c07bb66/attachment.htm From Lance.Corrimal at eregion.de Mon Mar 26 00:23:35 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 26 Mar 2012 07:23:35 -0000 Subject: [opensource-dev] Review Request: VWR-28535 - Current viewer-development build does not build on linux In-Reply-To: <20120326072252.4396.68373@domU-12-31-38-00-90-68.compute-1.internal> References: <20120326072252.4396.68373@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120326072335.5384.33389@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/568/ ----------------------------------------------------------- (Updated March 26, 2012, 12:23 a.m.) Review request for Viewer. Summary (updated) ----------------- VWR-28535 - Current viewer-development build does not build on linux Description ------- The current viewer-development tree does not compile cleanly on linux (at least not on my openSUSE 12.1 and openSUSE 11.4 systems). This addresses bug VWR-28535. http://jira.secondlife.com/browse/VWR-28535 Diffs ----- indra/llmath/llcoord.h 6943d3e9deb7 Diff: http://codereview.secondlife.com/r/568/diff/diff Testing ------- patched viewer-development 3.3.1 and viewer-release 3.3.0, builds fine, usage test shows no ill effects Thanks, Lance Corrimal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120326/e4a59dc7/attachment.htm From oz at lindenlab.com Mon Mar 26 09:10:44 2012 From: oz at lindenlab.com (Oz Linden) Date: Mon, 26 Mar 2012 16:10:44 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120325210749.4397.98410@domU-12-31-38-00-90-68.compute-1.internal> References: <20120325210749.4397.98410@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120326161044.4398.96870@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/565/#review1195 ----------------------------------------------------------- Ship it! indra/newview/pipeline.cpp Use F_PI here (yes, I know that was in the old code too) - Oz Linden On March 25, 2012, 2:07 p.m., Geenz Spad wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/565/ > ----------------------------------------------------------- > > (Updated March 25, 2012, 2:07 p.m.) > > > Review request for Viewer and David Parks. > > > Description > ------- > > For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. > > This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: > ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) > Where n is the specular exponent. > > Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. > > Test plan can be found in the JIRA. > Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp > > > This addresses bug STORM-1823. > http://jira.secondlife.com/browse/STORM-1823 > > > Diffs > ----- > > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > > Diff: http://codereview.secondlife.com/r/565/diff/diff > > > Testing > ------- > > * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance > * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such > * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) > * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance > > You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html > > > Thanks, > > Geenz Spad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120326/7d11c9b8/attachment-0001.htm From oz at lindenlab.com Mon Mar 26 09:15:20 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 26 Mar 2012 12:15:20 -0400 Subject: [opensource-dev] tired of the bad testting In-Reply-To: References: Message-ID: <4F709618.9070100@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120326/580a8199/attachment.htm From geenz at geenzo.com Mon Mar 26 10:46:07 2012 From: geenz at geenzo.com (Geenz Spad) Date: Mon, 26 Mar 2012 17:46:07 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120325210749.4397.98410@domU-12-31-38-00-90-68.compute-1.internal> References: <20120325210749.4397.98410@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120326174607.5952.10899@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/565/ ----------------------------------------------------------- (Updated March 26, 2012, 10:46 a.m.) Review request for Viewer and David Parks. Changes ------- Added the change that Oz requested, also updated contributions.txt while I was at it. Description ------- For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) Where n is the specular exponent. Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. Test plan can be found in the JIRA. Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp This addresses bug STORM-1823. http://jira.secondlife.com/browse/STORM-1823 Diffs (updated) ----- doc/contributions.txt b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/settings.xml b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/pipeline.h b32595c5170f92ac2dbab635955b1b86634f1475 indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 Diff: http://codereview.secondlife.com/r/565/diff/diff Testing ------- * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html Thanks, Geenz Spad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120326/5fc03012/attachment.htm From slitovchuk at productengine.com Mon Mar 26 11:12:42 2012 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Mon, 26 Mar 2012 18:12:42 -0000 Subject: [opensource-dev] Review Request: VWR-28535 - Current viewer-development build does not build on linux In-Reply-To: <20120326072335.5384.33389@domU-12-31-38-00-90-68.compute-1.internal> References: <20120326072335.5384.33389@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120326181242.4403.62460@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/568/#review1196 ----------------------------------------------------------- There is a fix to this problem, which does not involve changing the inheritance access specifiers. It should be soon merged to the viewer-development repo. Thanks for looking into it. - Seth ProductEngine On March 26, 2012, 12:23 a.m., Lance Corrimal wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/568/ > ----------------------------------------------------------- > > (Updated March 26, 2012, 12:23 a.m.) > > > Review request for Viewer. > > > Description > ------- > > The current viewer-development tree does not compile cleanly on linux (at least not on my openSUSE 12.1 and openSUSE 11.4 systems). > > > This addresses bug VWR-28535. > http://jira.secondlife.com/browse/VWR-28535 > > > Diffs > ----- > > indra/llmath/llcoord.h 6943d3e9deb7 > > Diff: http://codereview.secondlife.com/r/568/diff/diff > > > Testing > ------- > > patched viewer-development 3.3.1 and viewer-release 3.3.0, builds fine, usage test shows no ill effects > > > Thanks, > > Lance Corrimal > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120326/6cb1e174/attachment.htm From geenz at geenzo.com Mon Mar 26 17:24:01 2012 From: geenz at geenzo.com (Geenz Spad) Date: Tue, 27 Mar 2012 00:24:01 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120326174607.5952.10899@domU-12-31-38-00-90-68.compute-1.internal> References: <20120326174607.5952.10899@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120327002401.4396.52352@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/565/ ----------------------------------------------------------- (Updated March 26, 2012, 5:24 p.m.) Review request for Viewer and David Parks. Changes ------- Reduce the overall glow amount from the sun to a quarter of its original strength. This helps prevent specular highlights with glow applied from being too bright when compared to the previous specular model. Description ------- For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) Where n is the specular exponent. Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. Test plan can be found in the JIRA. Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp This addresses bug STORM-1823. http://jira.secondlife.com/browse/STORM-1823 Diffs (updated) ----- doc/contributions.txt UNKNOWN indra/newview/app_settings/settings.xml UNKNOWN indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN indra/newview/llviewercontrol.cpp UNKNOWN indra/newview/pipeline.h UNKNOWN indra/newview/pipeline.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/565/diff/diff Testing ------- * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html Thanks, Geenz Spad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120327/9fb27f38/attachment.htm From nickyperian at yahoo.com Mon Mar 26 19:37:42 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Tue, 27 Mar 2012 02:37:42 -0000 Subject: [opensource-dev] Review Request: OPEN-138 Sometimes the file character/new archetype.xml is not produced. Sometimes it is present after the viewer is closed. Sometimes it is present and can't be made to fail. Message-ID: <20120327023742.4931.90969@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/570/ ----------------------------------------------------------- Review request for Viewer. Description ------- Sometimes the file character/new archetype.xml is not produced. Sometimes it is present after the viewer is closed. Sometimes it is present and can't be made to fail. Intermittent write to character/new archetype.xml from Develop->Avatar-> Character Tests->Apperance To XML. Add explicit outfile.close() method before returning to caller. Add llinfos for file location as a troubleshooting aid. This addresses bug OPEN-138. http://jira.secondlife.com/browse/OPEN-138 Diffs ----- doc/contributions.txt 6943d3e9deb7 indra/newview/llvoavatar.cpp 6943d3e9deb7 Diff: http://codereview.secondlife.com/r/570/diff/diff Testing ------- First checked that the patch did no harm. Second seems more stable after running with the patch applied. Thanks, Nicky Perian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120327/c87e80df/attachment.htm From carlo at alinoe.com Mon Mar 26 20:05:20 2012 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 27 Mar 2012 05:05:20 +0200 Subject: [opensource-dev] tired of the bad testting In-Reply-To: <4F709618.9070100@lindenlab.com> References: <4F709618.9070100@lindenlab.com> Message-ID: <20120327050520.6d06b962@hikaru.localdomain> On Mon, 26 Mar 2012 12:15:20 -0400 "Oz Linden (Scott Lawrence)" wrote: > On 2012-03-25 23:56 , Flats Fixed wrote: > the latest stable came out. it broke the teleporters at 2100 meters. > you know guys this is not a jira this is simple testing. love the > new policy but the fact is the team is running people out of SL. test > it befor it goes stable. > > Perhaps you could provide a clear problem report? > > What software were you using? The latest stable. > What did you do? Try to teleport back after teleporting to 2100 meter. > What did you expect to happen? The same as with the older viewers. > What actually happened? It didn't work. From tateru.nino at gmail.com Mon Mar 26 20:10:28 2012 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue, 27 Mar 2012 14:10:28 +1100 Subject: [opensource-dev] tired of the bad testting In-Reply-To: <20120327050520.6d06b962@hikaru.localdomain> References: <4F709618.9070100@lindenlab.com> <20120327050520.6d06b962@hikaru.localdomain> Message-ID: <4F712FA4.30505@gmail.com> Are we talking the viewer's built-in teleportation, or scripted faux-teleportation (sithacks, etc)? On 27/03/2012 2:05 PM, Carlo Wood wrote: > On Mon, 26 Mar 2012 12:15:20 -0400 > "Oz Linden (Scott Lawrence)" wrote: > >> On 2012-03-25 23:56 , Flats Fixed wrote: >> the latest stable came out. it broke the teleporters at 2100 meters. >> you know guys this is not a jira this is simple testing. love the >> new policy but the fact is the team is running people out of SL. test >> it befor it goes stable. >> >> Perhaps you could provide a clear problem report? >> >> What software were you using? > The latest stable. > >> What did you do? > Try to teleport back after teleporting to 2100 meter. > >> What did you expect to happen? > The same as with the older viewers. > >> What actually happened? > It didn't work. > _______________________________________________ > 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 > From oz at lindenlab.com Tue Mar 27 05:57:39 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 27 Mar 2012 08:57:39 -0400 Subject: [opensource-dev] tired of the bad testting In-Reply-To: <20120327050520.6d06b962@hikaru.localdomain> References: <4F709618.9070100@lindenlab.com> <20120327050520.6d06b962@hikaru.localdomain> Message-ID: <4F71B943.1040102@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120327/fa8c2c09/attachment.htm From geenz at geenzo.com Tue Mar 27 09:54:53 2012 From: geenz at geenzo.com (Geenz Spad) Date: Tue, 27 Mar 2012 16:54:53 -0000 Subject: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity In-Reply-To: <20120327002401.4396.52352@domU-12-31-38-00-90-68.compute-1.internal> References: <20120327002401.4396.52352@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120327165453.4400.71862@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/565/ ----------------------------------------------------------- (Updated March 27, 2012, 9:54 a.m.) Review request for Viewer and David Parks. Changes ------- Updated build link. Description ------- For a while now, Second Life's deferred renderer has had a somewhat "toonish" looking specular model, as opposed to other platforms which try to go for more physically accurate looking models, such as blinn-phong and similar. This feature changes the specular model to a technique called normalized blinn-phong. The specular model applies the usual blinn-phong term (assume NdotV to the power of n), multiplied by a normalization function of: ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) Where n is the specular exponent. Gamma correction is also applied to the result to bring the visual results more in line with what you see in high end game engines such as Unreal Engine 3 and Frostbite 2, and stored in a lookup texture. Test plan can be found in the JIRA. Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp This addresses bug STORM-1823. http://jira.secondlife.com/browse/STORM-1823 Diffs ----- doc/contributions.txt UNKNOWN indra/newview/app_settings/settings.xml UNKNOWN indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN indra/newview/llviewercontrol.cpp UNKNOWN indra/newview/pipeline.h UNKNOWN indra/newview/pipeline.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/565/diff/diff Testing (updated) ------- * Tested performance characteristics - both Normalized Blinn-Phong and the previous model seem to have the same performance * Checked the perceived "brightness" of the new highlights vs. the old ones - new ones seem much brighter at higher shiny values than the old ones, and seem much less "cartoonish" as such * Checked the impact on different bumpiness values at the test rig at Hippo Hollow - noticeable visual improvement across all objects (though low shiny seems to have a much more subtle light reflectance term - this is expected for normalized blinn-phong) * Tested different LUT resolutions - best looking seems to be 512x128 with seemingly no measurable decrease in performance You can find the latest build here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/latest.html Thanks, Geenz Spad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120327/9e752c69/attachment-0001.htm From nickyperian at yahoo.com Tue Mar 27 11:15:23 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Tue, 27 Mar 2012 18:15:23 -0000 Subject: [opensource-dev] Review Request: STORM-1828 Sometimes the file character/new archetype.xml is not produced. Sometimes it is present after the viewer is closed. Sometimes it is present and can't be made to fail. In-Reply-To: <20120327023742.4931.90969@domU-12-31-38-00-90-68.compute-1.internal> References: <20120327023742.4931.90969@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120327181523.5900.48576@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/570/ ----------------------------------------------------------- (Updated March 27, 2012, 11:15 a.m.) Review request for Viewer. Summary (updated) ----------------- STORM-1828 Sometimes the file character/new archetype.xml is not produced. Sometimes it is present after the viewer is closed. Sometimes it is present and can't be made to fail. Description ------- Sometimes the file character/new archetype.xml is not produced. Sometimes it is present after the viewer is closed. Sometimes it is present and can't be made to fail. Intermittent write to character/new archetype.xml from Develop->Avatar-> Character Tests->Apperance To XML. Add explicit outfile.close() method before returning to caller. Add llinfos for file location as a troubleshooting aid. This addresses bug OPEN-138. http://jira.secondlife.com/browse/OPEN-138 Diffs ----- doc/contributions.txt 6943d3e9deb7 indra/newview/llvoavatar.cpp 6943d3e9deb7 Diff: http://codereview.secondlife.com/r/570/diff/diff Testing ------- First checked that the patch did no harm. Second seems more stable after running with the patch applied. Thanks, Nicky Perian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120327/b066561a/attachment.htm From nickyperian at yahoo.com Tue Mar 27 11:15:46 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Tue, 27 Mar 2012 18:15:46 -0000 Subject: [opensource-dev] Review Request: STORM-1828 Sometimes the file character/new archetype.xml is not produced. Sometimes it is present after the viewer is closed. Sometimes it is present and can't be made to fail. In-Reply-To: <20120327181523.5900.48576@domU-12-31-38-00-90-68.compute-1.internal> References: <20120327181523.5900.48576@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120327181546.4397.74968@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/570/ ----------------------------------------------------------- (Updated March 27, 2012, 11:15 a.m.) Review request for Viewer. Description ------- Sometimes the file character/new archetype.xml is not produced. Sometimes it is present after the viewer is closed. Sometimes it is present and can't be made to fail. Intermittent write to character/new archetype.xml from Develop->Avatar-> Character Tests->Apperance To XML. Add explicit outfile.close() method before returning to caller. Add llinfos for file location as a troubleshooting aid. This addresses bug STORM-1828. http://jira.secondlife.com/browse/STORM-1828 Diffs ----- doc/contributions.txt 6943d3e9deb7 indra/newview/llvoavatar.cpp 6943d3e9deb7 Diff: http://codereview.secondlife.com/r/570/diff/diff Testing ------- First checked that the patch did no harm. Second seems more stable after running with the patch applied. Thanks, Nicky Perian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120327/5113e0d4/attachment.htm From nickyperian at yahoo.com Tue Mar 27 11:53:30 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Tue, 27 Mar 2012 18:53:30 -0000 Subject: [opensource-dev] Review Request: STORM-1828 Sometimes the file character/new archetype.xml is not produced. Sometimes it is present after the viewer is closed. Sometimes it is present and can't be made to fail. In-Reply-To: <20120327181546.4397.74968@domU-12-31-38-00-90-68.compute-1.internal> References: <20120327181546.4397.74968@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120327185330.4396.42333@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/570/ ----------------------------------------------------------- (Updated March 27, 2012, 11:53 a.m.) Review request for Viewer. Changes ------- Set to moved to jira, STORM-1828, in commit message and contributions.txt Description ------- Sometimes the file character/new archetype.xml is not produced. Sometimes it is present after the viewer is closed. Sometimes it is present and can't be made to fail. Intermittent write to character/new archetype.xml from Develop->Avatar-> Character Tests->Apperance To XML. Add explicit outfile.close() method before returning to caller. Add llinfos for file location as a troubleshooting aid. This addresses bug STORM-1828. http://jira.secondlife.com/browse/STORM-1828 Diffs (updated) ----- doc/contributions.txt 6943d3e9deb7 indra/newview/llvoavatar.cpp 6943d3e9deb7 Diff: http://codereview.secondlife.com/r/570/diff/diff Testing ------- First checked that the patch did no harm. Second seems more stable after running with the patch applied. Thanks, Nicky Perian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120327/a556fba6/attachment.htm From Celierra at gmail.com Tue Mar 27 12:46:44 2012 From: Celierra at gmail.com (Celierra Darling) Date: Tue, 27 Mar 2012 15:46:44 -0400 Subject: [opensource-dev] tired of the bad testting In-Reply-To: <20120327050520.6d06b962@hikaru.localdomain> References: <4F709618.9070100@lindenlab.com> <20120327050520.6d06b962@hikaru.localdomain> Message-ID: On a more serious note, this is one way JIRA is useful - it helps walk users through reporting a problem clearly, so that we all can know what being referred to and its context, and we can start looking for possible causes. (Well, JIRA's more thorough, at least; the interface could still be improved so non-devs don't get lost....) Celi On Mon, Mar 26, 2012 at 11:05 PM, Carlo Wood wrote: > On Mon, 26 Mar 2012 12:15:20 -0400 > "Oz Linden (Scott Lawrence)" wrote: > > > On 2012-03-25 23:56 , Flats Fixed wrote: > > the latest stable came out. it broke the teleporters at 2100 meters. > > you know guys this is not a jira this is simple testing. love the > > new policy but the fact is the team is running people out of SL. test > > it befor it goes stable. > > > > Perhaps you could provide a clear problem report? > > > > What software were you using? > > The latest stable. > > > What did you do? > > Try to teleport back after teleporting to 2100 meter. > > > What did you expect to happen? > > The same as with the older viewers. > > > What actually happened? > > It didn't work. > _______________________________________________ > 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/20120327/3f074cf8/attachment.htm From oz at lindenlab.com Wed Mar 28 09:58:30 2012 From: oz at lindenlab.com (Oz Linden) Date: Wed, 28 Mar 2012 16:58:30 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 3.0 implementation. In-Reply-To: <20120323160102.19601.90176@domU-12-31-38-00-90-68.compute-1.internal> References: <20120323160102.19601.90176@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120328165830.4400.23332@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/566/#review1197 ----------------------------------------------------------- A couple of things to look at, but overall very very nice looking code. indra/newview/lllocalbitmaps.h Minor point ... it would be clearer to have the parameter be an enum whose values were first_use and texture_updated or something. Just because something only has two values doesn't make it a 'bool'. indra/newview/lllocalbitmaps.cpp Would an LL_WARN be appropriate here? indra/newview/lllocalbitmaps.cpp The cases in this switch all fall through if something unexpected happens... and there's no code to handle the unexpected. If falling through is intentional, there should be a comment saying so, and if not the break should follow the end of the (missing) else block. indra/newview/lllocalbitmaps.cpp you could shorten this loop by adding ' && add_object ' to the termination condition indra/newview/lllocalbitmaps.cpp clearer to put the assignment in the first clause of the for loop indra/newview/lllocalbitmaps.cpp I'd prefer a single 'return result;' at the bottom, replacing all those scattered ones with 'break;' because it's easier to set breakpoints on. - Oz Linden On March 23, 2012, 9:01 a.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/566/ > ----------------------------------------------------------- > > (Updated March 23, 2012, 9:01 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). > > *** DO NOT USE THIS YET *** > do not implement for live viewers until fully reviewed. > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 96a53bafcd1c > indra/newview/CMakeLists.txt 96a53bafcd1c > indra/newview/lllocalbitmaps.h PRE-CREATION > indra/newview/lllocalbitmaps.cpp PRE-CREATION > indra/newview/lltexturectrl.h 96a53bafcd1c > indra/newview/lltexturectrl.cpp 96a53bafcd1c > indra/newview/llviewertexturelist.h 96a53bafcd1c > indra/newview/llwearable.h 96a53bafcd1c > indra/newview/llwearable.cpp 96a53bafcd1c > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 96a53bafcd1c > > Diff: http://codereview.secondlife.com/r/566/diff/diff > > > Testing > ------- > > > Thanks, > > Vaalith Jinn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120328/f65dd568/attachment-0001.htm From oz at lindenlab.com Wed Mar 28 09:59:12 2012 From: oz at lindenlab.com (Oz Linden) Date: Wed, 28 Mar 2012 16:59:12 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 3.0 implementation. In-Reply-To: <20120323160102.19601.90176@domU-12-31-38-00-90-68.compute-1.internal> References: <20120323160102.19601.90176@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120328165912.4396.12263@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/566/ ----------------------------------------------------------- (Updated March 28, 2012, 9:59 a.m.) Review request for Viewer, Callum Linden and Richard Nelson. Description ------- Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). *** DO NOT USE THIS YET *** do not implement for live viewers until fully reviewed. This addresses bug STORM-64. http://jira.secondlife.com/browse/STORM-64 Diffs ----- doc/contributions.txt 96a53bafcd1c indra/newview/CMakeLists.txt 96a53bafcd1c indra/newview/lllocalbitmaps.h PRE-CREATION indra/newview/lllocalbitmaps.cpp PRE-CREATION indra/newview/lltexturectrl.h 96a53bafcd1c indra/newview/lltexturectrl.cpp 96a53bafcd1c indra/newview/llviewertexturelist.h 96a53bafcd1c indra/newview/llwearable.h 96a53bafcd1c indra/newview/llwearable.cpp 96a53bafcd1c indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 96a53bafcd1c Diff: http://codereview.secondlife.com/r/566/diff/diff Testing ------- Thanks, Vaalith Jinn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120328/3a75a403/attachment.htm From serpentu at gmail.com Thu Mar 29 05:12:52 2012 From: serpentu at gmail.com (Vaalith Jinn) Date: Thu, 29 Mar 2012 12:12:52 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 3.0 implementation. In-Reply-To: <20120328165912.4396.12263@domU-12-31-38-00-90-68.compute-1.internal> References: <20120328165912.4396.12263@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120329121252.4399.50326@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/566/ ----------------------------------------------------------- (Updated March 29, 2012, 5:12 a.m.) Review request for Viewer, Callum Linden and Richard Nelson. Changes ------- Included fd797a815c0a STORM-64: small fix for building on linux. Included 3e3ba231afb0 STORM-64: various fixes pointed out at codereview. Both of these already in the https://bitbucket.org/serpentu/storm-64-new repo. Description ------- Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). *** DO NOT USE THIS YET *** do not implement for live viewers until fully reviewed. This addresses bug STORM-64. http://jira.secondlife.com/browse/STORM-64 Diffs (updated) ----- doc/contributions.txt 96a53bafcd1c indra/newview/CMakeLists.txt 96a53bafcd1c indra/newview/lllocalbitmaps.h PRE-CREATION indra/newview/lllocalbitmaps.cpp PRE-CREATION indra/newview/lltexturectrl.h 96a53bafcd1c indra/newview/lltexturectrl.cpp 96a53bafcd1c indra/newview/llviewertexturelist.h 96a53bafcd1c indra/newview/llwearable.h 96a53bafcd1c indra/newview/llwearable.cpp 96a53bafcd1c indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 96a53bafcd1c Diff: http://codereview.secondlife.com/r/566/diff/diff Testing ------- Thanks, Vaalith Jinn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120329/fe1ccb86/attachment.htm From serpentu at gmail.com Thu Mar 29 05:28:11 2012 From: serpentu at gmail.com (Vaalith Jinn) Date: Thu, 29 Mar 2012 12:28:11 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 3.0 implementation. In-Reply-To: <20120329121252.4399.50326@domU-12-31-38-00-90-68.compute-1.internal> References: <20120329121252.4399.50326@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120329122811.4398.54009@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/566/#review1199 ----------------------------------------------------------- indra/newview/lllocalbitmaps.h For clarity's sake i kept private enums block below where it's currently at. If i were to add an enum value in here i'd have to either move the whole block up to keep consistency or break consistency and write in a single enum below the main public block.. Neither is a really pretty solution as far as readability is concerned. Is it really worth it? - Vaalith Jinn On March 29, 2012, 5:12 a.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/566/ > ----------------------------------------------------------- > > (Updated March 29, 2012, 5:12 a.m.) > > > Review request for Viewer, Callum Linden and Richard Nelson. > > > Description > ------- > > Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). > > *** DO NOT USE THIS YET *** > do not implement for live viewers until fully reviewed. > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 96a53bafcd1c > indra/newview/CMakeLists.txt 96a53bafcd1c > indra/newview/lllocalbitmaps.h PRE-CREATION > indra/newview/lllocalbitmaps.cpp PRE-CREATION > indra/newview/lltexturectrl.h 96a53bafcd1c > indra/newview/lltexturectrl.cpp 96a53bafcd1c > indra/newview/llviewertexturelist.h 96a53bafcd1c > indra/newview/llwearable.h 96a53bafcd1c > indra/newview/llwearable.cpp 96a53bafcd1c > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 96a53bafcd1c > > Diff: http://codereview.secondlife.com/r/566/diff/diff > > > Testing > ------- > > > Thanks, > > Vaalith Jinn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120329/fdb37180/attachment.htm From oz at lindenlab.com Fri Mar 30 06:16:24 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 30 Mar 2012 09:16:24 -0400 Subject: [opensource-dev] Old Showcase feed will soon be turned off Message-ID: <4F75B228.4040500@lindenlab.com> Several months ago, we made available the Viewer Web Widgets to be used to provide various ways of finding interesting places and events in Second Life, and they are now in use in many TPVs as well as our viewers. The Showcase feed those widgets replaced is going to be shut down soon, so if your viewer is still using it, now would be a good time to get the replacement integrated. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120330/6e91c2be/attachment.htm From oz at lindenlab.com Fri Mar 30 07:39:31 2012 From: oz at lindenlab.com (Oz Linden) Date: Fri, 30 Mar 2012 14:39:31 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 3.0 implementation. In-Reply-To: <20120329121252.4399.50326@domU-12-31-38-00-90-68.compute-1.internal> References: <20120329121252.4399.50326@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120330143931.9743.10103@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/566/#review1201 ----------------------------------------------------------- indra/newview/lllocalbitmaps.cpp Need 'break;' here. indra/newview/lllocalbitmaps.cpp Need 'break;' here. indra/newview/lllocalbitmaps.cpp Need 'break;' here. indra/newview/lllocalbitmaps.cpp log the fact that it's an unknown wearable type here? - Oz Linden On March 29, 2012, 5:12 a.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/566/ > ----------------------------------------------------------- > > (Updated March 29, 2012, 5:12 a.m.) > > > Review request for Viewer, Callum Linden and Richard Nelson. > > > Description > ------- > > Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). > > *** DO NOT USE THIS YET *** > do not implement for live viewers until fully reviewed. > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 96a53bafcd1c > indra/newview/CMakeLists.txt 96a53bafcd1c > indra/newview/lllocalbitmaps.h PRE-CREATION > indra/newview/lllocalbitmaps.cpp PRE-CREATION > indra/newview/lltexturectrl.h 96a53bafcd1c > indra/newview/lltexturectrl.cpp 96a53bafcd1c > indra/newview/llviewertexturelist.h 96a53bafcd1c > indra/newview/llwearable.h 96a53bafcd1c > indra/newview/llwearable.cpp 96a53bafcd1c > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 96a53bafcd1c > > Diff: http://codereview.secondlife.com/r/566/diff/diff > > > Testing > ------- > > > Thanks, > > Vaalith Jinn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120330/86a42354/attachment.htm From serpentu at gmail.com Fri Mar 30 16:06:11 2012 From: serpentu at gmail.com (Vaalith Jinn) Date: Fri, 30 Mar 2012 23:06:11 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 3.0 implementation. In-Reply-To: <20120329121252.4399.50326@domU-12-31-38-00-90-68.compute-1.internal> References: <20120329121252.4399.50326@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120330230611.5384.6033@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/566/ ----------------------------------------------------------- (Updated March 30, 2012, 4:06 p.m.) Review request for Viewer, Callum Linden and Richard Nelson. Changes ------- 5790e41deb9e STORM-64: Additional fixes from codereview. Description ------- Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). *** DO NOT USE THIS YET *** do not implement for live viewers until fully reviewed. This addresses bug STORM-64. http://jira.secondlife.com/browse/STORM-64 Diffs (updated) ----- doc/contributions.txt 96a53bafcd1c indra/newview/CMakeLists.txt 96a53bafcd1c indra/newview/lllocalbitmaps.h PRE-CREATION indra/newview/lllocalbitmaps.cpp PRE-CREATION indra/newview/lltexturectrl.h 96a53bafcd1c indra/newview/lltexturectrl.cpp 96a53bafcd1c indra/newview/llviewertexturelist.h 96a53bafcd1c indra/newview/llwearable.h 96a53bafcd1c indra/newview/llwearable.cpp 96a53bafcd1c indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 96a53bafcd1c Diff: http://codereview.secondlife.com/r/566/diff/diff Testing ------- Thanks, Vaalith Jinn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120330/2360e35c/attachment.htm From sllists at boroon.dasgupta.ch Fri Mar 30 17:20:04 2012 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 31 Mar 2012 00:20:04 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 3.0 implementation. In-Reply-To: <20120329122811.4398.54009@domU-12-31-38-00-90-68.compute-1.internal> References: <20120329122811.4398.54009@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120331002004.4401.30992@domU-12-31-38-00-90-68.compute-1.internal> > On March 29, 2012, 5:28 a.m., Vaalith Jinn wrote: > > indra/newview/lllocalbitmaps.h, line 42 > > > > > > For clarity's sake i kept private enums block below where it's currently at. > > > > If i were to add an enum value in here i'd have to either move the whole block up to keep consistency or break consistency and write in a single enum below the main public block.. > > > > Neither is a really pretty solution as far as readability is concerned. > > > > Is it really worth it? I think it'd be worth it, as it'd make the calling code much more readable. See http://doc.qt.nokia.com/qq/qq13-apis.html#thebooleanparametertrap Note that in the example at hand, the function will only be called with boolean literals, not boolean variables, so we don't have the problem of forcing additional if-else code onto the caller. Also, half if not all of the lengthy comment above the one place where you call the function with "true" could be saved if a well-named constant or enum would be passed instead. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/566/#review1199 ----------------------------------------------------------- On March 30, 2012, 4:06 p.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/566/ > ----------------------------------------------------------- > > (Updated March 30, 2012, 4:06 p.m.) > > > Review request for Viewer, Callum Linden and Richard Nelson. > > > Description > ------- > > Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). > > *** DO NOT USE THIS YET *** > do not implement for live viewers until fully reviewed. > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 96a53bafcd1c > indra/newview/CMakeLists.txt 96a53bafcd1c > indra/newview/lllocalbitmaps.h PRE-CREATION > indra/newview/lllocalbitmaps.cpp PRE-CREATION > indra/newview/lltexturectrl.h 96a53bafcd1c > indra/newview/lltexturectrl.cpp 96a53bafcd1c > indra/newview/llviewertexturelist.h 96a53bafcd1c > indra/newview/llwearable.h 96a53bafcd1c > indra/newview/llwearable.cpp 96a53bafcd1c > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 96a53bafcd1c > > Diff: http://codereview.secondlife.com/r/566/diff/diff > > > Testing > ------- > > > Thanks, > > Vaalith Jinn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120331/6a7dc251/attachment.htm From serpentu at gmail.com Fri Mar 30 18:38:26 2012 From: serpentu at gmail.com (Vaalith Jinn) Date: Sat, 31 Mar 2012 01:38:26 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 3.0 implementation. In-Reply-To: <20120329122811.4398.54009@domU-12-31-38-00-90-68.compute-1.internal> References: <20120329122811.4398.54009@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120331013826.4400.85587@domU-12-31-38-00-90-68.compute-1.internal> > On March 29, 2012, 5:28 a.m., Vaalith Jinn wrote: > > indra/newview/lllocalbitmaps.h, line 42 > > > > > > For clarity's sake i kept private enums block below where it's currently at. > > > > If i were to add an enum value in here i'd have to either move the whole block up to keep consistency or break consistency and write in a single enum below the main public block.. > > > > Neither is a really pretty solution as far as readability is concerned. > > > > Is it really worth it? > > Boroondas Gupte wrote: > I think it'd be worth it, as it'd make the calling code much more readable. See http://doc.qt.nokia.com/qq/qq13-apis.html#thebooleanparametertrap > > Note that in the example at hand, the function will only be called with boolean literals, not boolean variables, so we don't have the problem of forcing additional if-else code onto the caller. Also, half if not all of the lengthy comment above the one place where you call the function with "true" could be saved if a well-named constant or enum would be passed instead. Um... several questions: A) Unless i am misreading, are you implying that an enum would make it easier to understand than the existing albeit lengthy comment? B) The way i designed it is actually the way one would see the mechanism: The updateself function updates by default, it's what it does no more no less. The bool is there to indicate a special case, special because in the life of a single local bitmap object it is only used once and that is during it's creation. So to me it seems that forcing the function to take a "run regularly" enum parameter during each regular, non first-run call would be something akin to stating the obvious, which would seem redundant to me to the point of causing confusion. - Vaalith ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/566/#review1199 ----------------------------------------------------------- On March 30, 2012, 4:06 p.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/566/ > ----------------------------------------------------------- > > (Updated March 30, 2012, 4:06 p.m.) > > > Review request for Viewer, Callum Linden and Richard Nelson. > > > Description > ------- > > Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). > > *** DO NOT USE THIS YET *** > do not implement for live viewers until fully reviewed. > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 96a53bafcd1c > indra/newview/CMakeLists.txt 96a53bafcd1c > indra/newview/lllocalbitmaps.h PRE-CREATION > indra/newview/lllocalbitmaps.cpp PRE-CREATION > indra/newview/lltexturectrl.h 96a53bafcd1c > indra/newview/lltexturectrl.cpp 96a53bafcd1c > indra/newview/llviewertexturelist.h 96a53bafcd1c > indra/newview/llwearable.h 96a53bafcd1c > indra/newview/llwearable.cpp 96a53bafcd1c > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 96a53bafcd1c > > Diff: http://codereview.secondlife.com/r/566/diff/diff > > > Testing > ------- > > > Thanks, > > Vaalith Jinn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120331/85535694/attachment-0001.htm From sllists at boroon.dasgupta.ch Sat Mar 31 02:57:38 2012 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 31 Mar 2012 09:57:38 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 3.0 implementation. In-Reply-To: <20120329122811.4398.54009@domU-12-31-38-00-90-68.compute-1.internal> References: <20120329122811.4398.54009@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120331095738.4397.47903@domU-12-31-38-00-90-68.compute-1.internal> > On March 29, 2012, 5:28 a.m., Vaalith Jinn wrote: > > indra/newview/lllocalbitmaps.h, line 42 > > > > > > For clarity's sake i kept private enums block below where it's currently at. > > > > If i were to add an enum value in here i'd have to either move the whole block up to keep consistency or break consistency and write in a single enum below the main public block.. > > > > Neither is a really pretty solution as far as readability is concerned. > > > > Is it really worth it? > > Boroondas Gupte wrote: > I think it'd be worth it, as it'd make the calling code much more readable. See http://doc.qt.nokia.com/qq/qq13-apis.html#thebooleanparametertrap > > Note that in the example at hand, the function will only be called with boolean literals, not boolean variables, so we don't have the problem of forcing additional if-else code onto the caller. Also, half if not all of the lengthy comment above the one place where you call the function with "true" could be saved if a well-named constant or enum would be passed instead. > > Vaalith Jinn wrote: > Um... several questions: > > A) Unless i am misreading, are you implying that an enum would make it easier to understand than the existing albeit lengthy comment? > > B) The way i designed it is actually the way one would see the mechanism: The updateself function updates by default, it's what it does no more no less. > The bool is there to indicate a special case, special because in the life of a single local bitmap object it is only used once and that is during it's creation. > > So to me it seems that forcing the function to take a "run regularly" enum parameter during each regular, non first-run call would be something akin to stating the obvious, > which would seem redundant to me to the point of causing confusion. A) Yes, that's what I'm implying. It might not be true for every reader, just as there is no single writing style that can be considered more understandable to everyone then every other writing style. But for many (me included), switching between reading comments written in natural language and code in a programming language requires a little effort, so one tends to either read just the code, skipping over just the comments, or the comments, skipping over the code. A good use of both seems to try explaining *what* you do with the code itself and *why* you do it (if not obvious) in the comments. The advantage for self-explanatory code over comments it that it is precise, up-to-date and "true". If code gets changed and comments are not adapted accordingly, remaining out-of-date comments might confuse or even mislead the reader. (Maybe unlikely to become an issue right here, but this is an important point I took away from reading Robert C. Martin's "Clean Code" book.) B) Can't enum arguments have default values, too? - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/566/#review1199 ----------------------------------------------------------- On March 30, 2012, 4:06 p.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/566/ > ----------------------------------------------------------- > > (Updated March 30, 2012, 4:06 p.m.) > > > Review request for Viewer, Callum Linden and Richard Nelson. > > > Description > ------- > > Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). > > *** DO NOT USE THIS YET *** > do not implement for live viewers until fully reviewed. > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 96a53bafcd1c > indra/newview/CMakeLists.txt 96a53bafcd1c > indra/newview/lllocalbitmaps.h PRE-CREATION > indra/newview/lllocalbitmaps.cpp PRE-CREATION > indra/newview/lltexturectrl.h 96a53bafcd1c > indra/newview/lltexturectrl.cpp 96a53bafcd1c > indra/newview/llviewertexturelist.h 96a53bafcd1c > indra/newview/llwearable.h 96a53bafcd1c > indra/newview/llwearable.cpp 96a53bafcd1c > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 96a53bafcd1c > > Diff: http://codereview.secondlife.com/r/566/diff/diff > > > Testing > ------- > > > Thanks, > > Vaalith Jinn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120331/d4b5c144/attachment.htm From oz at lindenlab.com Sat Mar 31 13:15:02 2012 From: oz at lindenlab.com (Oz Linden) Date: Sat, 31 Mar 2012 20:15:02 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 3.0 implementation. In-Reply-To: <20120329122811.4398.54009@domU-12-31-38-00-90-68.compute-1.internal> References: <20120329122811.4398.54009@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120331201502.5384.48267@domU-12-31-38-00-90-68.compute-1.internal> > On March 29, 2012, 5:28 a.m., Vaalith Jinn wrote: > > well said, Boroondas Yes, it's clearer to use the enum, and yes an enum parameter can have a default > On March 29, 2012, 5:28 a.m., Vaalith Jinn wrote: > > indra/newview/lllocalbitmaps.h, line 42 > > > > > > For clarity's sake i kept private enums block below where it's currently at. > > > > If i were to add an enum value in here i'd have to either move the whole block up to keep consistency or break consistency and write in a single enum below the main public block.. > > > > Neither is a really pretty solution as far as readability is concerned. > > > > Is it really worth it? > > Boroondas Gupte wrote: > I think it'd be worth it, as it'd make the calling code much more readable. See http://doc.qt.nokia.com/qq/qq13-apis.html#thebooleanparametertrap > > Note that in the example at hand, the function will only be called with boolean literals, not boolean variables, so we don't have the problem of forcing additional if-else code onto the caller. Also, half if not all of the lengthy comment above the one place where you call the function with "true" could be saved if a well-named constant or enum would be passed instead. > > Vaalith Jinn wrote: > Um... several questions: > > A) Unless i am misreading, are you implying that an enum would make it easier to understand than the existing albeit lengthy comment? > > B) The way i designed it is actually the way one would see the mechanism: The updateself function updates by default, it's what it does no more no less. > The bool is there to indicate a special case, special because in the life of a single local bitmap object it is only used once and that is during it's creation. > > So to me it seems that forcing the function to take a "run regularly" enum parameter during each regular, non first-run call would be something akin to stating the obvious, > which would seem redundant to me to the point of causing confusion. > > Boroondas Gupte wrote: > A) Yes, that's what I'm implying. It might not be true for every reader, just as there is no single writing style that can be considered more understandable to everyone then every other writing style. But for many (me included), switching between reading comments written in natural language and code in a programming language requires a little effort, so one tends to either read just the code, skipping over just the comments, or the comments, skipping over the code. A good use of both seems to try explaining *what* you do with the code itself and *why* you do it (if not obvious) in the comments. > > The advantage for self-explanatory code over comments it that it is precise, up-to-date and "true". If code gets changed and comments are not adapted accordingly, remaining out-of-date comments might confuse or even mislead the reader. (Maybe unlikely to become an issue right here, but this is an important point I took away from reading Robert C. Martin's "Clean Code" book.) > > B) Can't enum arguments have default values, too? Since the enum would be part of the interface to the public function, it shouldn't be private, and belongs right there next to the method: typedef enum { FIRST_USE, REPLACING } UpdateType; bool updateSelf(UpdateType usage); and then the test inside the method becomes: if (FIRST_USE == usage) - Oz ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/566/#review1199 ----------------------------------------------------------- On March 30, 2012, 4:06 p.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/566/ > ----------------------------------------------------------- > > (Updated March 30, 2012, 4:06 p.m.) > > > Review request for Viewer, Callum Linden and Richard Nelson. > > > Description > ------- > > Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). > > *** DO NOT USE THIS YET *** > do not implement for live viewers until fully reviewed. > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 96a53bafcd1c > indra/newview/CMakeLists.txt 96a53bafcd1c > indra/newview/lllocalbitmaps.h PRE-CREATION > indra/newview/lllocalbitmaps.cpp PRE-CREATION > indra/newview/lltexturectrl.h 96a53bafcd1c > indra/newview/lltexturectrl.cpp 96a53bafcd1c > indra/newview/llviewertexturelist.h 96a53bafcd1c > indra/newview/llwearable.h 96a53bafcd1c > indra/newview/llwearable.cpp 96a53bafcd1c > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 96a53bafcd1c > > Diff: http://codereview.secondlife.com/r/566/diff/diff > > > Testing > ------- > > > Thanks, > > Vaalith Jinn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120331/af5dc096/attachment.htm