From nickyperian at yahoo.com Sat Dec 1 09:30:03 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Sat, 01 Dec 2012 17:30:03 -0000 Subject: [opensource-dev] Review Request: Fix for STORM-1854. In-Reply-To: <20121201011745.21465.67942@domU-12-31-38-00-90-68.compute-1.internal> References: <20121201011745.21465.67942@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20121201173003.21465.58666@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/609/#review1278 ----------------------------------------------------------- Kokua's approach was to updated the libs and deliver them using viewer_manifest.py. Using the updated libs/includes I get the following compiler error. It appears when the libs are LL updated this mod will need to be backed out. ?static std::vector, std::allocator >, std::allocator, std::allocator > > > LLWindowSDL::getDynamicFallbackFontList()?: /home/bill/kokua-dev-q/indra/llwindow/llwindowsdl.cpp:2651: error: cannot convert ?FcResult? to ?FcResult*? for argument ?5? to ?FcFontSet* FcFontSort(FcConfig*, FcPattern*, FcBool, FcCharSet**, FcResult*)? - Nicky Perian On Nov. 30, 2012, 5:17 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/609/ > ----------------------------------------------------------- > > (Updated Nov. 30, 2012, 5:17 p.m.) > > > Review request for Viewer. > > > Description > ------- > > This is a fix for STORM-1854. It prevents an assert failure that happens during viewer startup on linux systems with a sufficiently new version of the fontconfig library (I think fontconfig 1.9). It should not impact mac or windows because those platforms do not use llwindowsdl.cpp file, which was the only file changed. > > > This addresses bug STORM-1854. > http://jira.secondlife.com/browse/STORM-1854 > > > Diffs > ----- > > indra/llwindow/llwindowsdl.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/609/diff/ > > > Testing > ------- > > This change builds successfully on all three platforms (Teamcity). I have verified that the startup error no longer occurs on Ubuntu 12.10. Ideally we would test that Linux systems with older versions of fontconfig can also still start the viewer, but I don't have easy access to one of those. > > > Thanks, > > Log Linden > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121201/235984ce/attachment.htm From sllists at boroon.dasgupta.ch Sat Dec 1 14:59:45 2012 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 01 Dec 2012 22:59:45 -0000 Subject: [opensource-dev] Review Request: Fix for STORM-1854. In-Reply-To: <20121201173003.21465.58666@domU-12-31-38-00-90-68.compute-1.internal> References: <20121201173003.21465.58666@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20121201225945.23751.18274@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 1, 2012, 9:30 a.m., Nicky Perian wrote: > > Kokua's approach was to updated the libs and deliver them using viewer_manifest.py. > > Using the updated libs/includes I get the following compiler error. > > It appears when the libs are LL updated this mod will need to be backed out. > > > > ?static std::vector, std::allocator >, std::allocator, std::allocator > > > > > LLWindowSDL::getDynamicFallbackFontList()?: > > /home/bill/kokua-dev-q/indra/llwindow/llwindowsdl.cpp:2651: error: cannot convert ?FcResult? to ?FcResult*? for argument ?5? to ?FcFontSet* FcFontSort(FcConfig*, FcPattern*, FcBool, FcCharSet**, FcResult*)? > > Odd. To me, it looks like the new code would be passing a FcResult*, not a FcResult. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/609/#review1278 ----------------------------------------------------------- On Nov. 30, 2012, 5:17 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/609/ > ----------------------------------------------------------- > > (Updated Nov. 30, 2012, 5:17 p.m.) > > > Review request for Viewer. > > > Description > ------- > > This is a fix for STORM-1854. It prevents an assert failure that happens during viewer startup on linux systems with a sufficiently new version of the fontconfig library (I think fontconfig 1.9). It should not impact mac or windows because those platforms do not use llwindowsdl.cpp file, which was the only file changed. > > > This addresses bug STORM-1854. > http://jira.secondlife.com/browse/STORM-1854 > > > Diffs > ----- > > indra/llwindow/llwindowsdl.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/609/diff/ > > > Testing > ------- > > This change builds successfully on all three platforms (Teamcity). I have verified that the startup error no longer occurs on Ubuntu 12.10. Ideally we would test that Linux systems with older versions of fontconfig can also still start the viewer, but I don't have easy access to one of those. > > > Thanks, > > Log Linden > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121201/8173eaf3/attachment.htm From jaeger_Reg at hotmail.com Sat Dec 1 15:47:27 2012 From: jaeger_Reg at hotmail.com (Tankmaster Finesmith) Date: Sat, 01 Dec 2012 23:47:27 -0000 Subject: [opensource-dev] Review Request: Fix for STORM-1854. In-Reply-To: <20121201011745.21465.67942@domU-12-31-38-00-90-68.compute-1.internal> References: <20121201011745.21465.67942@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20121201234727.21463.13029@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/609/#review1280 ----------------------------------------------------------- Ship it! Ship It! - Tankmaster Finesmith On Nov. 30, 2012, 5:17 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/609/ > ----------------------------------------------------------- > > (Updated Nov. 30, 2012, 5:17 p.m.) > > > Review request for Viewer. > > > Description > ------- > > This is a fix for STORM-1854. It prevents an assert failure that happens during viewer startup on linux systems with a sufficiently new version of the fontconfig library (I think fontconfig 1.9). It should not impact mac or windows because those platforms do not use llwindowsdl.cpp file, which was the only file changed. > > > This addresses bug STORM-1854. > http://jira.secondlife.com/browse/STORM-1854 > > > Diffs > ----- > > indra/llwindow/llwindowsdl.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/609/diff/ > > > Testing > ------- > > This change builds successfully on all three platforms (Teamcity). I have verified that the startup error no longer occurs on Ubuntu 12.10. Ideally we would test that Linux systems with older versions of fontconfig can also still start the viewer, but I don't have easy access to one of those. > > > Thanks, > > Log Linden > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121201/065eb109/attachment.htm From jaeger_Reg at hotmail.com Sat Dec 1 15:47:38 2012 From: jaeger_Reg at hotmail.com (Tankmaster Finesmith) Date: Sat, 01 Dec 2012 23:47:38 -0000 Subject: [opensource-dev] Review Request: Fix for STORM-1854. In-Reply-To: <20121201234727.21463.13029@domU-12-31-38-00-90-68.compute-1.internal> References: <20121201234727.21463.13029@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20121201234738.5881.14426@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 1, 2012, 3:47 p.m., Tankmaster Finesmith wrote: > > Ship It! the approach in this diff is the same NickyD used in firestorm. WE haven't had issues with it so far - Tankmaster ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/609/#review1280 ----------------------------------------------------------- On Nov. 30, 2012, 5:17 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/609/ > ----------------------------------------------------------- > > (Updated Nov. 30, 2012, 5:17 p.m.) > > > Review request for Viewer. > > > Description > ------- > > This is a fix for STORM-1854. It prevents an assert failure that happens during viewer startup on linux systems with a sufficiently new version of the fontconfig library (I think fontconfig 1.9). It should not impact mac or windows because those platforms do not use llwindowsdl.cpp file, which was the only file changed. > > > This addresses bug STORM-1854. > http://jira.secondlife.com/browse/STORM-1854 > > > Diffs > ----- > > indra/llwindow/llwindowsdl.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/609/diff/ > > > Testing > ------- > > This change builds successfully on all three platforms (Teamcity). I have verified that the startup error no longer occurs on Ubuntu 12.10. Ideally we would test that Linux systems with older versions of fontconfig can also still start the viewer, but I don't have easy access to one of those. > > > Thanks, > > Log Linden > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121201/965ded20/attachment.htm From nickyperian at yahoo.com Sat Dec 1 16:00:04 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Sun, 02 Dec 2012 00:00:04 -0000 Subject: [opensource-dev] Review Request: Fix for STORM-1854. In-Reply-To: <20121201011745.21465.67942@domU-12-31-38-00-90-68.compute-1.internal> References: <20121201011745.21465.67942@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20121202000004.23816.26198@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/609/#review1282 ----------------------------------------------------------- https://bitbucket.org/log_linden/viewer-storm-1854/commits/cf7ad502c7c3/ does not match this diff. result should be &result - Nicky Perian On Nov. 30, 2012, 5:17 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/609/ > ----------------------------------------------------------- > > (Updated Nov. 30, 2012, 5:17 p.m.) > > > Review request for Viewer. > > > Description > ------- > > This is a fix for STORM-1854. It prevents an assert failure that happens during viewer startup on linux systems with a sufficiently new version of the fontconfig library (I think fontconfig 1.9). It should not impact mac or windows because those platforms do not use llwindowsdl.cpp file, which was the only file changed. > > > This addresses bug STORM-1854. > http://jira.secondlife.com/browse/STORM-1854 > > > Diffs > ----- > > indra/llwindow/llwindowsdl.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/609/diff/ > > > Testing > ------- > > This change builds successfully on all three platforms (Teamcity). I have verified that the startup error no longer occurs on Ubuntu 12.10. Ideally we would test that Linux systems with older versions of fontconfig can also still start the viewer, but I don't have easy access to one of those. > > > Thanks, > > Log Linden > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121202/da3d64d2/attachment-0001.htm From nickyperian at yahoo.com Sat Dec 1 21:00:53 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Sun, 02 Dec 2012 05:00:53 -0000 Subject: [opensource-dev] Review Request: Fix for STORM-1854. In-Reply-To: <20121201011745.21465.67942@domU-12-31-38-00-90-68.compute-1.internal> References: <20121201011745.21465.67942@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20121202050053.6630.86599@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/609/#review1284 ----------------------------------------------------------- Ship it! Compiled linux 32 and 64 bit with the updated freetype and fontconfig libraries. Ran fine on debain squeeze and ubuntu 12.10. - Nicky Perian On Nov. 30, 2012, 5:17 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/609/ > ----------------------------------------------------------- > > (Updated Nov. 30, 2012, 5:17 p.m.) > > > Review request for Viewer. > > > Description > ------- > > This is a fix for STORM-1854. It prevents an assert failure that happens during viewer startup on linux systems with a sufficiently new version of the fontconfig library (I think fontconfig 1.9). It should not impact mac or windows because those platforms do not use llwindowsdl.cpp file, which was the only file changed. > > > This addresses bug STORM-1854. > http://jira.secondlife.com/browse/STORM-1854 > > > Diffs > ----- > > indra/llwindow/llwindowsdl.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/609/diff/ > > > Testing > ------- > > This change builds successfully on all three platforms (Teamcity). I have verified that the startup error no longer occurs on Ubuntu 12.10. Ideally we would test that Linux systems with older versions of fontconfig can also still start the viewer, but I don't have easy access to one of those. > > > Thanks, > > Log Linden > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121202/e5faaf37/attachment.htm From sllists at boroon.dasgupta.ch Sun Dec 2 02:37:11 2012 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 02 Dec 2012 10:37:11 -0000 Subject: [opensource-dev] Review Request: Fix for STORM-1854. In-Reply-To: <20121201011745.21465.67942@domU-12-31-38-00-90-68.compute-1.internal> References: <20121201011745.21465.67942@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20121202103711.6630.19277@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/609/#review1286 ----------------------------------------------------------- Ship it! Ship It! - Boroondas Gupte On Nov. 30, 2012, 5:17 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/609/ > ----------------------------------------------------------- > > (Updated Nov. 30, 2012, 5:17 p.m.) > > > Review request for Viewer. > > > Description > ------- > > This is a fix for STORM-1854. It prevents an assert failure that happens during viewer startup on linux systems with a sufficiently new version of the fontconfig library (I think fontconfig 1.9). It should not impact mac or windows because those platforms do not use llwindowsdl.cpp file, which was the only file changed. > > > This addresses bug STORM-1854. > http://jira.secondlife.com/browse/STORM-1854 > > > Diffs > ----- > > indra/llwindow/llwindowsdl.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/609/diff/ > > > Testing > ------- > > This change builds successfully on all three platforms (Teamcity). I have verified that the startup error no longer occurs on Ubuntu 12.10. Ideally we would test that Linux systems with older versions of fontconfig can also still start the viewer, but I don't have easy access to one of those. > > > Thanks, > > Log Linden > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121202/e3dc39e7/attachment.htm From sllists at boroon.dasgupta.ch Sun Dec 2 02:37:23 2012 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 02 Dec 2012 10:37:23 -0000 Subject: [opensource-dev] Review Request: Fix for STORM-1854. In-Reply-To: <20121202000004.23816.26198@domU-12-31-38-00-90-68.compute-1.internal> References: <20121202000004.23816.26198@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20121202103723.6759.63231@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 1, 2012, 4 p.m., Nicky Perian wrote: > > https://bitbucket.org/log_linden/viewer-storm-1854/commits/cf7ad502c7c3/ does not match this diff. result should be &result Got fixed in https://bitbucket.org/log_linden/viewer-storm-1854/commits/b418be80903520c492e1173f3afbc4021cad5d07 - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/609/#review1282 ----------------------------------------------------------- On Nov. 30, 2012, 5:17 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/609/ > ----------------------------------------------------------- > > (Updated Nov. 30, 2012, 5:17 p.m.) > > > Review request for Viewer. > > > Description > ------- > > This is a fix for STORM-1854. It prevents an assert failure that happens during viewer startup on linux systems with a sufficiently new version of the fontconfig library (I think fontconfig 1.9). It should not impact mac or windows because those platforms do not use llwindowsdl.cpp file, which was the only file changed. > > > This addresses bug STORM-1854. > http://jira.secondlife.com/browse/STORM-1854 > > > Diffs > ----- > > indra/llwindow/llwindowsdl.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/609/diff/ > > > Testing > ------- > > This change builds successfully on all three platforms (Teamcity). I have verified that the startup error no longer occurs on Ubuntu 12.10. Ideally we would test that Linux systems with older versions of fontconfig can also still start the viewer, but I don't have easy access to one of those. > > > Thanks, > > Log Linden > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121202/723512a3/attachment.htm From c at yotes.com Sun Dec 2 02:51:44 2012 From: c at yotes.com (Tofu Buzzard) Date: Sun, 02 Dec 2012 10:51:44 -0000 Subject: [opensource-dev] Review Request: OPEN-152 Fog is broken on water, and extra-broken on water in deferred rendering Message-ID: <20121202105144.6627.80043@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/611/ ----------------------------------------------------------- Review request for Viewer. Description ------- Made deferred water use the atmospheric helper shader functions properly, made fog calculation view-relative rather than absolute-position in deferred and non-deferred windlight shaders. Diffs ----- doc/contributions.txt UNKNOWN indra/newview/app_settings/shaders/class1/deferred/waterF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/waterV.glsl UNKNOWN indra/newview/app_settings/shaders/class1/environment/waterV.glsl UNKNOWN indra/newview/llviewershadermgr.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/611/diff/ Testing ------- Tested with/without deferred rendering, with various sky presets. Screenshots ----------- before/after comparisons http://codereview.secondlife.com/r/611/s/1/ Thanks, Tofu Buzzard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121202/34e6f41b/attachment.htm From c at yotes.com Sun Dec 2 02:52:07 2012 From: c at yotes.com (Tofu Buzzard) Date: Sun, 02 Dec 2012 10:52:07 -0000 Subject: [opensource-dev] Review Request: OPEN-152 Fog is broken on water, and extra-broken on water in deferred rendering In-Reply-To: <20121202105144.6627.80043@domU-12-31-38-00-90-68.compute-1.internal> References: <20121202105144.6627.80043@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20121202105207.6934.5939@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/611/ ----------------------------------------------------------- (Updated Dec. 2, 2012, 2:52 a.m.) Review request for Viewer. Description ------- Made deferred water use the atmospheric helper shader functions properly, made fog calculation view-relative rather than absolute-position in deferred and non-deferred windlight shaders. Diffs ----- doc/contributions.txt UNKNOWN indra/newview/app_settings/shaders/class1/deferred/waterF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/waterV.glsl UNKNOWN indra/newview/app_settings/shaders/class1/environment/waterV.glsl UNKNOWN indra/newview/llviewershadermgr.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/611/diff/ Testing ------- Tested with/without deferred rendering, with various sky presets. Screenshots ----------- before/after comparisons http://codereview.secondlife.com/r/611/s/1/ Thanks, Tofu Buzzard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121202/aa8ef54c/attachment-0001.htm From c at yotes.com Sun Dec 2 02:53:45 2012 From: c at yotes.com (Tofu Buzzard) Date: Sun, 02 Dec 2012 10:53:45 -0000 Subject: [opensource-dev] Review Request: OPEN-152 Fog is broken on water, and extra-broken on water in deferred rendering In-Reply-To: <20121202105207.6934.5939@domU-12-31-38-00-90-68.compute-1.internal> References: <20121202105207.6934.5939@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20121202105345.6630.26356@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/611/ ----------------------------------------------------------- (Updated Dec. 2, 2012, 2:53 a.m.) Review request for Viewer. Description ------- Made deferred water use the atmospheric helper shader functions properly, made fog calculation view-relative rather than absolute-position in deferred and non-deferred windlight shaders. This addresses bug OPEN-152. http://jira.secondlife.com/browse/OPEN-152 Diffs ----- doc/contributions.txt UNKNOWN indra/newview/app_settings/shaders/class1/deferred/waterF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/waterV.glsl UNKNOWN indra/newview/app_settings/shaders/class1/environment/waterV.glsl UNKNOWN indra/newview/llviewershadermgr.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/611/diff/ Testing ------- Tested with/without deferred rendering, with various sky presets. Screenshots ----------- before/after comparisons http://codereview.secondlife.com/r/611/s/1/ Thanks, Tofu Buzzard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121202/d12db6ee/attachment.htm From c at yotes.com Sun Dec 2 03:49:57 2012 From: c at yotes.com (Tofu Buzzard) Date: Sun, 02 Dec 2012 11:49:57 -0000 Subject: [opensource-dev] Review Request: VWR-29083 Make SSAO work better Message-ID: <20121202114957.6626.55980@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/612/ ----------------------------------------------------------- Review request for Viewer. Description ------- Use a different scheme for weighting SSAO samples, apply SSAO before fog is applied, fix a bug in the screen-space shadow/ssao smoothing offset where the 'checkerboard' stipple had been refactored incorrectly, change some default settings in line with the resulting visual changes. Also, improve comments a bit. :3 This addresses bug VWR-29083. http://jira.secondlife.com/browse/VWR-29083 Diffs ----- doc/contributions.txt UNKNOWN indra/llrender/llshadermgr.h UNKNOWN indra/llrender/llshadermgr.cpp UNKNOWN indra/newview/app_settings/settings.xml UNKNOWN indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl UNKNOWN indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl UNKNOWN indra/newview/pipeline.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/612/diff/ Testing ------- Been running with this for months on an assortment of nvidia hardware, linux only. Thanks, Tofu Buzzard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121202/661c7ec8/attachment.htm From celierra at gmail.com Sun Dec 2 09:23:12 2012 From: celierra at gmail.com (Celierra Darling) Date: Sun, 02 Dec 2012 17:23:12 -0000 Subject: [opensource-dev] Review Request: VWR-29083 Make SSAO work better In-Reply-To: <20121202114957.6626.55980@domU-12-31-38-00-90-68.compute-1.internal> References: <20121202114957.6626.55980@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20121202172312.7159.39203@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/612/#review1288 ----------------------------------------------------------- Hey Tofu! :3 indra/newview/app_settings/settings.xml I still think it might be valuable to attenuate (HSV) saturation, but since it'd been stuck at 1.0 since forever and it doesn't look like it'll be exposed in Environment Settings anytime soon... *shrug* Used like this, RenderSSAOEffect might be entirely redundant with RenderSSAOFactor, if I remember correctly? indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl Where's the code where ssao_effect_mat had been constructed? (If it's not being used, it should probably be taken out too.) indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl This line can probably go too. (It got removed in class2 but not class1; maybe check for more?) indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl The 'if' here might be problematic.. I remember some cards were choking on branches, thus the convoluted lines that looked like new = old + int(conditional)*value. (same for class1) Also, I could have sworn that there used to be comments here specifying what the non-mangled math originally was (a la the old softenLightF.glsl:206-214).... indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl Won't using norm.xyz*diff raw like this cause false positives (from self-occlusion)? IIRC, that was why the old code used dot(samp-0.05*norm-pos, norm). (todo for self: render this for one sample to check...) (same for class1) indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl Out of curiosity, why a minimum, instead of ex. "(angrel>0) ? distrel : 0.0" ? Seems odd in cases of 0 < angrel < distrel. (No longer using the sphere assumption?) - Celierra Darling On Dec. 2, 2012, 3:49 a.m., Tofu Buzzard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/612/ > ----------------------------------------------------------- > > (Updated Dec. 2, 2012, 3:49 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Use a different scheme for weighting SSAO samples, apply SSAO before fog is applied, fix a bug in the screen-space shadow/ssao smoothing offset where the 'checkerboard' stipple had been refactored incorrectly, change some default settings in line with the resulting visual changes. Also, improve comments a bit. :3 > > > This addresses bug VWR-29083. > http://jira.secondlife.com/browse/VWR-29083 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/llrender/llshadermgr.h UNKNOWN > indra/llrender/llshadermgr.cpp UNKNOWN > indra/newview/app_settings/settings.xml UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl UNKNOWN > indra/newview/pipeline.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/612/diff/ > > > Testing > ------- > > Been running with this for months on an assortment of nvidia hardware, linux only. > > > Thanks, > > Tofu Buzzard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121202/6c034c50/attachment-0001.htm From kadah.coba at gmail.com Wed Dec 5 10:46:37 2012 From: kadah.coba at gmail.com (Kadah) Date: Wed, 05 Dec 2012 10:46:37 -0800 Subject: [opensource-dev] software development In-Reply-To: <2500021.BimJXfLfgs@sai> References: <2500021.BimJXfLfgs@sai> Message-ID: <50BF968D.4060501@gmail.com> On 11/20/2012 3:22 AM, Lance Corrimal wrote: > http://www.sandraandwoo.com/2012/11/19/0430-software-engineering-now-with- > cats/ Good one. x3 From sitearm at gmail.com Fri Dec 7 18:41:44 2012 From: sitearm at gmail.com (Sitearm) Date: Fri, 7 Dec 2012 20:41:44 -0600 Subject: [opensource-dev] MOSES Office Hours DSG Test 07-Dec-2012 01 In-Reply-To: References: Message-ID: ; December 8, 2012 ? sitearm [image: MOSES Office Hours DSG Test 07-Dec-2012 01] *The MOSES Community *is a professional, online networking group researching the ability of OpenSimulator platforms to provide independent, high-security, high-performance access to three-dimensional, online, interactive virtual environments. *Distributed Scene Graph (DSG)* is a technology developed by Intel Corporation to enable 3D web experiences to extend to massive numbers of OpenSim users. *Hot topic* at today?s MOSES Office Hours was a test of the MOSES region running on dual servers connected by Intel?s Distributed Scene Graph (DSG) technology. DSG allows massive numbers of OpenSim users to interact live with each other without lag. For today?s test, 12 logged into region mosesdsg2, and 12 logged into mosesdsg5; yet each one of the 24 could see every other one of the 24, and chat and communicate together. Users were logged in from 9 states, and 3 countries. The Office Hours load test is part of preparations for much larger exercises to be conducted by STTC. Intel members of the MOSES Community include Robert Adams, Mic Bowman, Dan Lake, and Kitty Liu. *Selected quotes* *Bandwidth increases quadratically with the number of users. For n users, each making a move, the server sends n(n-1) updates. * n=2; 2 updates n=5; 20 updates n=10; 90 updates n=20; 380 updates n=50; 2,450 updates n=100; 9,900 updates n=200; 3,980 updates n=500; 249,500 updates n>500; n*n updates See also: U.S. Army Offers MOSES 3D Web System for Non-Army Researchers Distributed scene graph to enable thousands of interacting users Military Open Simulator Enterprise Strategy (home page) Posted in 3D Web , MOSES, News . Leave a Comment ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121207/9bfa5bbe/attachment.htm From nickyperian at yahoo.com Sun Dec 9 18:32:18 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Sun, 9 Dec 2012 18:32:18 -0800 (PST) Subject: [opensource-dev] Linux boost shared libraries Message-ID: <1355106738.33211.YahooMailNeo@web126103.mail.ne1.yahoo.com> What is the reason for the switch to boost shared libraries? The other platforms seem to perform without issue using boost static libraries.? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121209/da361869/attachment.htm From monty at lindenlab.com Mon Dec 10 08:56:57 2012 From: monty at lindenlab.com (Monty Brandenberg) Date: Mon, 10 Dec 2012 11:56:57 -0500 Subject: [opensource-dev] Linux boost shared libraries In-Reply-To: <1355106738.33211.YahooMailNeo@web126103.mail.ne1.yahoo.com> References: <1355106738.33211.YahooMailNeo@web126103.mail.ne1.yahoo.com> Message-ID: <50C61459.2040905@lindenlab.com> On 12/9/2012 9:32 PM, Nicky Perian wrote: > > What is the reason for the switch to boost shared libraries? > > The other platforms seem to perform without issue using boost static > libraries. In 3.4.3? That change was picked up as part of some shared work in Boost packaging. Not certain what the technical motivation was. Are you seeing a problem as a result? (I expect it will likely revert on a future refresh of Boost, probably 1.52 but no promises there.) m From nickyperian at yahoo.com Mon Dec 10 09:50:58 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Mon, 10 Dec 2012 09:50:58 -0800 (PST) Subject: [opensource-dev] Linux boost shared libraries In-Reply-To: <50C61459.2040905@lindenlab.com> References: <1355106738.33211.YahooMailNeo@web126103.mail.ne1.yahoo.com> <50C61459.2040905@lindenlab.com> Message-ID: <1355161858.8510.YahooMailNeo@web126104.mail.ne1.yahoo.com> Yes, 3.4.3 No problem with LL v-d(1.52) or v-b(1.48). I build a 64 bit viewer for kokua and built it w/o the *.so but, did not link icu to the viewer. It built and runs Ok "i think". Just may not have reached the code where it it is needed. From Oz meeting this morning the shared libs are for boost regex. But, I still don't understand the need. The static libs are built against icu so the icu functions should be in boost regex *.a. The viewer is linked to the static so why is shared needed? ? And, if shared are needed for linux why are they not needed for windows and darwin? >________________________________ > From: Monty Brandenberg >To: opensource-dev at lists.secondlife.com >Sent: Monday, December 10, 2012 10:56 AM >Subject: Re: [opensource-dev] Linux boost shared libraries > >On 12/9/2012 9:32 PM, Nicky Perian wrote: >> >> What is the reason for the switch to boost shared libraries? >> >> The other platforms seem to perform without issue using boost static >> libraries. > >In 3.4.3?? That change was picked up as part of some shared work >in Boost packaging.? Not certain what the technical motivation >was.? Are you seeing a problem as a result? > >(I expect it will likely revert on a future refresh of Boost, >probably 1.52 but no promises there.) > >m > > >_______________________________________________ >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/20121210/d77c0863/attachment.htm From sldev at free.fr Mon Dec 10 12:36:41 2012 From: sldev at free.fr (Henri Beauchamp) Date: Mon, 10 Dec 2012 21:36:41 +0100 Subject: [opensource-dev] Linux boost shared libraries In-Reply-To: <1355106738.33211.YahooMailNeo@web126103.mail.ne1.yahoo.com> References: <1355106738.33211.YahooMailNeo@web126103.mail.ne1.yahoo.com> Message-ID: <20121210213641.1bfda73a.sldev@free.fr> On Sun, 9 Dec 2012 18:32:18 -0800 (PST), Nicky Perian wrote: > What is the reason for the switch to boost shared libraries? > > The other platforms seem to perform without issue using boost static libraries.? Apart from adding 20Mb of shared libraries (boost regexp) to the viewer package ?... There's strictly no good reason ! I vote for getting back to static libraries (the few regex functions that get statically linked only take a few kilobytes in the viewer binary, when the boost regex shared lib is enormous and 99% of it is usless to the viewer !) Henri. From nickyperian at yahoo.com Mon Dec 10 13:53:12 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Mon, 10 Dec 2012 21:53:12 -0000 Subject: [opensource-dev] Review Request: OPEN-151. Provide an openal and gstreamer plugin streaming audio implementation. In-Reply-To: <20121112035352.20143.92715@domU-12-31-38-00-90-68.compute-1.internal> References: <20121112035352.20143.92715@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20121210215312.24059.16949@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/604/ ----------------------------------------------------------- (Updated Dec. 10, 2012, 1:53 p.m.) Review request for Viewer. Changes ------- Add stream titles. This adds a minimal stream artist and title to chat. No whitelist/blacklist code. Description ------- Provide an openal and gstreamer plugin streaming audio implementation. Port from Kokua viewer as a starting point. Uses windows has a proof of concept platform. History of work started with Imprudence so there are many try patches that may not be needed and the work started before emphasis on style that is used today. This addresses bug OPEN-151. http://jira.secondlife.com/browse/OPEN-151 Diffs (updated) ----- autobuild.xml 9539c10021ba doc/contributions.txt 9539c10021ba indra/cmake/Copy3rdPartyLibs.cmake 9539c10021ba indra/cmake/GStreamer010Plugin.cmake 9539c10021ba indra/cmake/OPENAL.cmake 9539c10021ba indra/llmessage/llcurl.h 9539c10021ba indra/llmessage/llcurl.cpp 9539c10021ba indra/llplugin/llpluginclassmedia.h 9539c10021ba indra/llplugin/llpluginclassmedia.cpp 9539c10021ba indra/llplugin/llplugininstance.cpp 9539c10021ba indra/llplugin/llpluginprocesschild.h 9539c10021ba indra/llplugin/llpluginprocesschild.cpp 9539c10021ba indra/llplugin/llpluginprocessparent.h 9539c10021ba indra/llplugin/llpluginprocessparent.cpp 9539c10021ba indra/media_plugins/gstreamer010/CMakeLists.txt 9539c10021ba indra/media_plugins/gstreamer010/llmediaimplgstreamer.h 9539c10021ba indra/media_plugins/gstreamer010/llmediaimplgstreamertriviallogging.h 9539c10021ba indra/media_plugins/gstreamer010/llmediaimplgstreamervidplug.h 9539c10021ba indra/media_plugins/gstreamer010/llmediaimplgstreamervidplug.cpp 9539c10021ba indra/media_plugins/gstreamer010/media_plugin_gstreamer010.cpp 9539c10021ba indra/media_plugins/webkit/media_plugin_webkit.cpp 9539c10021ba indra/newview/CMakeLists.txt 9539c10021ba indra/newview/llviewermedia.cpp 9539c10021ba indra/newview/llviewermedia_streamingaudio.cpp 9539c10021ba indra/newview/skins/default/xui/en/mime_types.xml 9539c10021ba indra/newview/skins/default/xui/en/mime_types_mac.xml 9539c10021ba indra/newview/skins/default/xui/en/notifications.xml 9539c10021ba indra/newview/viewer_manifest.py 9539c10021ba Diff: http://codereview.secondlife.com/r/604/diff/ Testing ------- Logged to parcel with streaming audio. Stream present. Paused stream. Stream paused. Resumed stream. Stream playing. Toggled music check mark in preferences to off/on. Stream off / Stream on. Teleport to another parcel with a different stream. Old stream stops and new stream plays. Teleport back to starting point. Original stream plays. Thanks, Nicky Perian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121210/691968b7/attachment.htm From nickyperian at yahoo.com Mon Dec 10 16:25:37 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Mon, 10 Dec 2012 16:25:37 -0800 (PST) Subject: [opensource-dev] Linux boost shared libraries In-Reply-To: <20121210213641.1bfda73a.sldev@free.fr> References: <1355106738.33211.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121210213641.1bfda73a.sldev@free.fr> Message-ID: <1355185537.17172.YahooMailNeo@web126103.mail.ne1.yahoo.com> At the sldev meeting earlier it was stated that unicode processing with boost regex was problematic unless a shared boost lib was included. Here:?http://www.boost.org/doc/libs/1_52_0/libs/regex/doc/html/boost_regex/unicode.html it appears that the static lib compiled/linked with ICU is unicode aware. am i wrong? >________________________________ > From: Henri Beauchamp >To: opensource-dev at lists.secondlife.com >Sent: Monday, December 10, 2012 2:36 PM >Subject: Re: [opensource-dev] Linux boost shared libraries > >On Sun, 9 Dec 2012 18:32:18 -0800 (PST), Nicky Perian wrote: > >> What is the reason for the switch to boost shared libraries? >> >> The other platforms seem to perform without issue using boost static libraries.? > >Apart from adding 20Mb of shared libraries (boost regexp) to the viewer >package ?... There's strictly no good reason ! > >I vote for getting back to static libraries (the few regex functions that >get statically linked only take a few kilobytes in the viewer binary, when >the boost regex shared lib is enormous and 99% of it is usless to the >viewer !) > >Henri. >_______________________________________________ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121210/83fc9529/attachment.htm From monty at lindenlab.com Mon Dec 10 20:07:14 2012 From: monty at lindenlab.com (Monty Brandenberg) Date: Mon, 10 Dec 2012 23:07:14 -0500 Subject: [opensource-dev] Linux boost shared libraries In-Reply-To: <1355185537.17172.YahooMailNeo@web126103.mail.ne1.yahoo.com> References: <1355106738.33211.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121210213641.1bfda73a.sldev@free.fr> <1355185537.17172.YahooMailNeo@web126103.mail.ne1.yahoo.com> Message-ID: <50C6B172.1050803@lindenlab.com> On 12/10/2012 7:25 PM, Nicky Perian wrote: > At the sldev meeting earlier it was stated that unicode processing with > boost regex was problematic unless a shared boost lib was included. > Here: http://www.boost.org/doc/libs/1_52_0/libs/regex/doc/html/boost_regex/unicode.html > it appears that the static lib compiled/linked with ICU is unicode aware. I think we need some unit/integration tests to probe what we're trying to achieve with ::regex. Grumble. From sldev at free.fr Tue Dec 11 02:03:36 2012 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 11 Dec 2012 11:03:36 +0100 Subject: [opensource-dev] Linux boost shared libraries In-Reply-To: <1355185537.17172.YahooMailNeo@web126103.mail.ne1.yahoo.com> References: <1355106738.33211.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121210213641.1bfda73a.sldev@free.fr> <1355185537.17172.YahooMailNeo@web126103.mail.ne1.yahoo.com> Message-ID: <20121211110336.491e927c.sldev@free.fr> On Mon, 10 Dec 2012 16:25:37 -0800 (PST), Nicky Perian wrote: > At the sldev meeting earlier it was stated that unicode processing with boost > regex was problematic unless a shared boost lib was included. Here: >?http://www.boost.org/doc/libs/1_52_0/libs/regex/doc/html/boost_regex/unicode.html > it appears that the static lib compiled/linked with ICU is unicode aware. Yes, it is if the boost library was built on a system with ICU installed. Here is the relevant info for how to build boost::regex with Unicode support: http://www.boost.org/doc/libs/1_52_0/libs/regex/doc/html/boost_regex/install.html#boost_regex.install.building_with_unicode_and_icu_support Henri. From monty at lindenlab.com Tue Dec 11 10:02:51 2012 From: monty at lindenlab.com (Monty Brandenberg) Date: Tue, 11 Dec 2012 13:02:51 -0500 Subject: [opensource-dev] Linux boost shared libraries In-Reply-To: <20121211110336.491e927c.sldev@free.fr> References: <1355106738.33211.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121210213641.1bfda73a.sldev@free.fr> <1355185537.17172.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121211110336.491e927c.sldev@free.fr> Message-ID: <50C7754B.4040902@lindenlab.com> filed: https://jira.secondlife.com/browse/BUG-1056 From sldev at free.fr Tue Dec 11 14:36:33 2012 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 11 Dec 2012 23:36:33 +0100 Subject: [opensource-dev] Linux boost shared libraries In-Reply-To: <50C7754B.4040902@lindenlab.com> References: <1355106738.33211.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121210213641.1bfda73a.sldev@free.fr> <1355185537.17172.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121211110336.491e927c.sldev@free.fr> <50C7754B.4040902@lindenlab.com> Message-ID: <20121211233633.5583e636.sldev@free.fr> On Tue, 11 Dec 2012 13:02:51 -0500, Monty Brandenberg wrote: > filed: https://jira.secondlife.com/browse/BUG-1056 "Permission Violation" The JIRA became useless to developers and users alike... From monty at lindenlab.com Tue Dec 11 15:18:15 2012 From: monty at lindenlab.com (Monty Brandenberg) Date: Tue, 11 Dec 2012 18:18:15 -0500 Subject: [opensource-dev] Linux boost shared libraries In-Reply-To: <20121211233633.5583e636.sldev@free.fr> References: <1355106738.33211.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121210213641.1bfda73a.sldev@free.fr> <1355185537.17172.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121211110336.491e927c.sldev@free.fr> <50C7754B.4040902@lindenlab.com> <20121211233633.5583e636.sldev@free.fr> Message-ID: <50C7BF37.3090707@lindenlab.com> On 12/11/2012 5:36 PM, Henri Beauchamp wrote: > The JIRA became useless to developers and users alike... Not useless, _streamlined_! *cough* From oz at lindenlab.com Fri Dec 14 13:40:58 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 14 Dec 2012 16:40:58 -0500 Subject: [opensource-dev] Upcoming server side avatar baking Message-ID: <50CB9CEA.3000509@lindenlab.com> For any of you developing viewers that are not in the TPV Directory and so didn't get the notice there.... We have now made available the code for our upcoming server side baking changes - you will need to update to be compatible with this in order for users to see avatars correctly once the server side change is rolled out to the main grid (some time > 8 weeks from now, but no date has been set yet). See https://wiki.secondlife.com/wiki/Project_Sunshine-Server_Side_Appearance for information on this new code, and watch it for updates. From sldev at free.fr Mon Dec 17 00:43:11 2012 From: sldev at free.fr (Henri Beauchamp) Date: Mon, 17 Dec 2012 09:43:11 +0100 Subject: [opensource-dev] Upcoming server side avatar baking In-Reply-To: <50CB9CEA.3000509@lindenlab.com> References: <50CB9CEA.3000509@lindenlab.com> Message-ID: <20121217094311.051b20aa.sldev@free.fr> On Fri, 14 Dec 2012 16:40:58 -0500, Oz Linden (Scott Lawrence) wrote: > For any of you developing viewers that are not in the TPV Directory and > so didn't get the notice there.... > > We have now made available the code for our upcoming server side baking > changes - you will need to update to be compatible with this in order > for users to see avatars correctly once the server side change is rolled > out to the main grid (some time > 8 weeks from now, but no date has been > set yet). > > See > https://wiki.secondlife.com/wiki/Project_Sunshine-Server_Side_Appearance > for information on this new code, and watch it for updates. Alas, the said repository doesn't match any of viewer-release, viewer-beta or viewer-development code, making it impossible to get a clean diff of the actual, related, relevant changes. The diff I get against any of the three public branches of the viewer is over 2Mb big and contains changes to the UI, the path finding tools, the renderer (llrender and pipeline), the vfs, and many more cruft that seems (but it's hard to be 100% sure for everything without carefully studying the code) totally unrelated with the server side baking changes. Could you please provide a repository which is the copy of the one that was used to implement server side baking changes but that would be clean of those changes (this way, we could create a clean diff containing only the relevant changes, which would help immensely and prevent long trial and error sessions figuring out what is needed or not) ? I also deeply regret that you took the hard-coded approach (making the baking code rely on a hard-coded inventory tree) and used the COF directory to pick up the texture IDs to use in the bake (this should have been provided as a list by the viewer, so that the inventory structure is only dependent on the UI of the said viewer and on how the users wish to arrange their own inventory). One of the flaws of your approach is that your baking system can't detect when a change is done to a wearable that is being worn (you admit it yourself in the Wiki page, indicating yet another capability will be needed to signal such a case)... A poor implementation choice, IMHO. Regards, Henri. From nickyperian at yahoo.com Mon Dec 17 05:35:06 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Mon, 17 Dec 2012 05:35:06 -0800 (PST) Subject: [opensource-dev] Upcoming server side avatar baking In-Reply-To: <20121217094311.051b20aa.sldev@free.fr> References: <50CB9CEA.3000509@lindenlab.com> <20121217094311.051b20aa.sldev@free.fr> Message-ID: <1355751306.96429.YahooMailNeo@web126103.mail.ne1.yahoo.com> Henri I was able to merge and build and verify kokua on aditi; the top 2 commits are post merge tweaks. I don't know if that can help diff wise but, feel free to use. The last upstream merge to kokua was viewer-release, last Monday's merge. Nicky https://bitbucket.org/NickyP/kokua-sunshine-external/overview >________________________________ > From: Henri Beauchamp >To: Oz Linden (Scott Lawrence) >Cc: opensource-dev >Sent: Monday, December 17, 2012 2:43 AM >Subject: Re: [opensource-dev] Upcoming server side avatar baking > >On Fri, 14 Dec 2012 16:40:58 -0500, Oz Linden (Scott Lawrence) wrote: > >> For any of you developing viewers that are not in the TPV Directory and >> so didn't get the notice there.... >> >> We have now made available the code for our upcoming server side baking >> changes - you will need to update to be compatible with this in order >> for users to see avatars correctly once the server side change is rolled >> out to the main grid (some time > 8 weeks from now, but no date has been >> set yet). >> >> See >> https://wiki.secondlife.com/wiki/Project_Sunshine-Server_Side_Appearance >> for information on this new code, and watch it for updates. > >Alas, the said repository doesn't match any of viewer-release, viewer-beta >or viewer-development code, making it impossible to get a clean diff of >the actual, related, relevant changes. > >The diff I get against any of the three public branches of the viewer is >over 2Mb big and contains changes to the UI, the path finding tools, the >renderer (llrender and pipeline), the vfs, and many more cruft that seems >(but it's hard to be 100% sure for everything without carefully studying >the code) totally unrelated with the server side baking changes. > >Could you please provide a repository which is the copy of the one that >was used to implement server side baking changes but that would be clean >of those changes (this way, we could create a clean diff containing only >the relevant changes, which would help immensely and prevent long trial >and error sessions figuring out what is needed or not) ? > >I also deeply regret that you took the hard-coded approach (making the >baking code rely on a hard-coded inventory tree) and used the COF >directory to pick up the texture IDs to use in the bake (this should >have been provided as a list by the viewer, so that the inventory >structure is only dependent on the UI of the said viewer and on how >the users wish to arrange their own inventory). One of the flaws of >your approach is that your baking system can't detect when a change >is done to a wearable that is being worn (you admit it yourself in >the Wiki page, indicating yet another capability will be needed to >signal such a case)... A poor implementation choice, IMHO. > >Regards, > >Henri. >_______________________________________________ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121217/fac03093/attachment.htm From sldev at free.fr Mon Dec 17 07:54:05 2012 From: sldev at free.fr (Henri Beauchamp) Date: Mon, 17 Dec 2012 16:54:05 +0100 Subject: [opensource-dev] Upcoming server side avatar baking In-Reply-To: <1355751306.96429.YahooMailNeo@web126103.mail.ne1.yahoo.com> References: <50CB9CEA.3000509@lindenlab.com> <20121217094311.051b20aa.sldev@free.fr> <1355751306.96429.YahooMailNeo@web126103.mail.ne1.yahoo.com> Message-ID: <20121217165405.34406884.sldev@free.fr> On Mon, 17 Dec 2012 05:35:06 -0800 (PST), Nicky Perian wrote: > Henri > I was able to merge and build and verify kokua on aditi; the top 2 commits are post merge tweaks. I don't know if that can help diff wise but, feel free to use. > The last upstream merge to kokua was viewer-release, last Monday's merge. > Nicky > https://bitbucket.org/NickyP/kokua-sunshine-external/overview I'm afraid it doesn't help. What I need to avoid wasting my little free time in this period of the year, is a clean diff with only the *relevant*, *minimal* changes in it. The fact you could merge the sunshine branch with another v3-based viewer doesn't help (you simply merged stuff that is still not validated/adopted/committed to the viewer-development and viewer-beta banches together the (soon) mandatory server side baking code). Regards, Henri. From nickyperian at yahoo.com Mon Dec 17 09:18:04 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Mon, 17 Dec 2012 09:18:04 -0800 (PST) Subject: [opensource-dev] Upcoming server side avatar baking In-Reply-To: <20121217165405.34406884.sldev@free.fr> References: <50CB9CEA.3000509@lindenlab.com> <20121217094311.051b20aa.sldev@free.fr> <1355751306.96429.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121217165405.34406884.sldev@free.fr> Message-ID: <1355764684.11254.YahooMailNeo@web126106.mail.ne1.yahoo.com> I fail to see how?anyone's?time (LL devs included) is more or less valuable during the upcoming holidays. You can work this through to diff using hg by: clone the sunshine repo. find the point of first sunshine commit. update to it give it a sunshine bookmark or branch. doesn't matter which update to tip and do a dummy commit (may not be needed) clone viewer-development pull the sunshine branch into v-d do not update or merge the branch hg graft the beginning to end sunshine branch change sets resolve the merges as you go once done the sunshine branch will be re-based to the front of v-d change the phase of all the cs, if not allready, to draft import all to mq un-apply all but first fold all the un-applied to the first? export a patch/diff. ? this is more or less the procedure i have used to cherry pick. >________________________________ > From: Henri Beauchamp >To: opensource-dev at lists.secondlife.com >Sent: Monday, December 17, 2012 9:54 AM >Subject: Re: [opensource-dev] Upcoming server side avatar baking > >On Mon, 17 Dec 2012 05:35:06 -0800 (PST), Nicky Perian wrote: > >> Henri >> I was able to merge and build and verify kokua on aditi; the top 2 commits are post merge tweaks. I don't know if that can help diff wise but, feel free to use. >> The last upstream merge to kokua was viewer-release, last Monday's merge. >> Nicky >> https://bitbucket.org/NickyP/kokua-sunshine-external/overview > >I'm afraid it doesn't help. What I need to avoid wasting my little >free time in this period of the year, is a clean diff with only the >*relevant*, *minimal* changes in it. > >The fact you could merge the sunshine branch with another v3-based >viewer doesn't help (you simply merged stuff that is still not >validated/adopted/committed to the viewer-development and viewer-beta >banches together the (soon) mandatory server side baking code). > >Regards, > >Henri. >_______________________________________________ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121217/54effa7b/attachment-0001.htm From sldev at free.fr Mon Dec 17 11:24:37 2012 From: sldev at free.fr (Henri Beauchamp) Date: Mon, 17 Dec 2012 20:24:37 +0100 Subject: [opensource-dev] Upcoming server side avatar baking In-Reply-To: <1355764684.11254.YahooMailNeo@web126106.mail.ne1.yahoo.com> References: <50CB9CEA.3000509@lindenlab.com> <20121217094311.051b20aa.sldev@free.fr> <1355751306.96429.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121217165405.34406884.sldev@free.fr> <1355764684.11254.YahooMailNeo@web126106.mail.ne1.yahoo.com> Message-ID: <20121217202437.000f44d3.sldev@free.fr> On Mon, 17 Dec 2012 09:18:04 -0800 (PST), Nicky Perian wrote: > I fail to see how?anyone's?time (LL devs included) is more or less valuable during the upcoming holidays. > > You can work this through to diff using hg by: > > clone the sunshine repo. > find the point of first sunshine commit. > update to it > give it a sunshine bookmark or branch. doesn't matter which > update to tip and do a dummy commit (may not be needed) > clone viewer-development > pull the sunshine branch into v-d do not update or merge the branch > hg graft the beginning to end sunshine branch change sets > resolve the merges as you go > once done the sunshine branch will be re-based to the front of v-d > change the phase of all the cs, if not allready, to draft > import all to mq > un-apply all but first > fold all the un-applied to the first? > export a patch/diff. > ? > this is more or less the procedure i have used to cherry pick. Excepted that: 1.- the initial sunchine repo (from which the server baking branch was forked: sunshine-internal ?) is not public; 2.- the first changes happened months ago and now that sunshine-external was merged with viewer-develompent, it becomes impossible to distinguish what commit was applied to what branch (repos are a mess ! I always hated them !); 3.- I don't have the time to browse some 850+ pages of commits to see when and which commit is relevant to the new code or not (it would be simpler and faster for me to clean up by hand the diff between viewer-develompent and sunshine-external) ! It would be MUCH simpler for LL to just clone the original repo (*they* know when the repo was branched and what was the first commit to it), merge the viewer-development commits into it (the same commits they merged in the sunshine-external repo) and make the clone public. I would then just download the sources for that clone and diff it with sunshine-external: done ! All changes at hand in a single diff, and all relevant to the actual task at hand. Henri. From oz at lindenlab.com Mon Dec 17 13:18:59 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 17 Dec 2012 16:18:59 -0500 Subject: [opensource-dev] Upcoming server side avatar baking In-Reply-To: <20121217094311.051b20aa.sldev@free.fr> References: <50CB9CEA.3000509@lindenlab.com> <20121217094311.051b20aa.sldev@free.fr> Message-ID: <50CF8C43.1060707@lindenlab.com> On 2012-12-17 03:43 , Henri Beauchamp wrote: > On Fri, 14 Dec 2012 16:40:58 -0500, Oz Linden (Scott Lawrence) wrote: > >> For any of you developing viewers that are not in the TPV Directory and >> so didn't get the notice there.... >> >> We have now made available the code for our upcoming server side baking >> changes - you will need to update to be compatible with this in order >> for users to see avatars correctly once the server side change is rolled >> out to the main grid (some time > 8 weeks from now, but no date has been >> set yet). >> >> See >> https://wiki.secondlife.com/wiki/Project_Sunshine-Server_Side_Appearance >> for information on this new code, and watch it for updates. > Alas, the said repository doesn't match any of viewer-release, viewer-beta > or viewer-development code, making it impossible to get a clean diff of > the actual, related, relevant changes. > > The diff I get against any of the three public branches of the viewer is > over 2Mb big and contains changes to the UI, the path finding tools, the > renderer (llrender and pipeline), the vfs, and many more cruft that seems > (but it's hard to be 100% sure for everything without carefully studying > the code) totally unrelated with the server side baking changes. > > Could you please provide a repository which is the copy of the one that > was used to implement server side baking changes but that would be clean > of those changes (this way, we could create a clean diff containing only > the relevant changes, which would help immensely and prevent long trial > and error sessions figuring out what is needed or not) ? No, we can't, sorry. That project has been in development for some months. They have done very significant refactoring in order to better organize the code around avatar appearance, and have merged out from viewer-development a number of times. The entire history is in the repository you can see, which is ultimately derived from an earlier version of viewer-development (you're just as capable of finding that fork point as anyone else is). Yes, there are lots and lots of changes here. > I also deeply regret that you took the hard-coded approach (making the > baking code rely on a hard-coded inventory tree) and used the COF > directory to pick up the texture IDs to use in the bake (this should > have been provided as a list by the viewer, so that the inventory > structure is only dependent on the UI of the said viewer and on how > the users wish to arrange their own inventory). One of the flaws of > your approach is that your baking system can't detect when a change > is done to a wearable that is being worn (you admit it yourself in > the Wiki page, indicating yet another capability will be needed to > signal such a case)... A poor implementation choice, IMHO. I'm sure that there were any number of fundamental design decisions that could have been made differently, but our purpose here is not to either revisit those debates or to explain why we made the choices we did. The fundamental design decisions have been made, and we're going to proceed with the design we've got. If you have questions about how the code works, and especially the new messages exchanged regarding avatar appearance, ask them here and we'll do what we can to help. From latifer at streamgrid.net Mon Dec 17 20:53:02 2012 From: latifer at streamgrid.net (Latif Khalifa) Date: Tue, 18 Dec 2012 05:53:02 +0100 Subject: [opensource-dev] Upcoming server side avatar baking In-Reply-To: <50CF8C43.1060707@lindenlab.com> References: <50CB9CEA.3000509@lindenlab.com> <20121217094311.051b20aa.sldev@free.fr> <50CF8C43.1060707@lindenlab.com> Message-ID: On Mon, Dec 17, 2012 at 10:18 PM, Oz Linden (Scott Lawrence) wrote: > I'm sure that there were any number of fundamental design decisions that > could have been made differently, but our purpose here is not to either > revisit those debates or to explain why we made the choices we did. The > fundamental design decisions have been made, and we're going to proceed > with the design we've got. People who don't fancy themselves to be the infallible gods of system design often find it beneficial to hear the feedback, especially in opensource projects. It might even lead to (gasp) more reliable system and better customer satisfaction. Whenever I relapse into using my time to help improve Linden Lab's products by doing testing, filing bug reports and repro cases, Oz Linden's attitude quickly convinces me that it's not worth it. (This email started as my feedback about some timing issue with network messages that could potentially cause bake fails, but then I saw all-knowing Oz dismiss any need for it) From sldev at free.fr Tue Dec 18 01:32:15 2012 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 18 Dec 2012 10:32:15 +0100 Subject: [opensource-dev] OpenSource reciprocal help (was: Re: Upcoming server side avatar baking) In-Reply-To: <50CF8C43.1060707@lindenlab.com> References: <50CB9CEA.3000509@lindenlab.com> <20121217094311.051b20aa.sldev@free.fr> <50CF8C43.1060707@lindenlab.com> Message-ID: <20121218103215.782656c3.sldev@free.fr> On Mon, 17 Dec 2012 16:18:59 -0500, Oz Linden (Scott Lawrence) wrote: > On 2012-12-17 03:43 , Henri Beauchamp wrote: > > On Fri, 14 Dec 2012 16:40:58 -0500, Oz Linden (Scott Lawrence) wrote: > > > > .../... > > Could you please provide a repository which is the copy of the one that > > was used to implement server side baking changes but that would be clean > > of those changes (this way, we could create a clean diff containing only > > the relevant changes, which would help immensely and prevent long trial > > and error sessions figuring out what is needed or not) ? > > No, we can't, sorry. Did you ever say "yes" and actually provide any kind of useful help to an OpenSource developer ?... I'm yet to find a case in which that happened... You, know, the time I spend sorting out LL's mess, I don't spend it providing you with bugfixes (even if, because of the stupid CA stuff, I must find convoluted ways to contribute, such as the private emails I already sent to you to point out and explain nasty bugs in your code). FYI, there are currently two nasty bugs in the renderer code that I was investigating: - one bug deals with the new idleUpdate() code that was recently introduced in LL's v3 viewers and that I so far put on hold in my viewer because it causes bad issues (disappearing objects out of the FOV) when the camera mode is set to CAMERA_MODE_CUSTOMIZE_AVATAR (it seems that v3 viewers don't use this mode any more, even if the code is still there, but that's plain silly because the preview thumbnails (dynamic textures) in the wearable editor are then showing your avatar from the back or in random posistions instead of having it facing the camera). - another, even more serious bug, deals with scripted, punctually moving objects (sliding and rotating doors, for example), which position fails to be updated in the renderer when they are off the camera FOV; click on an auto-closing door to open it, then turn away from it so that it's no more in the FOV and wait till it closes automatically, then turn around again to face it: surprise, it appears as still open (but it's not: you'd bump into it and right-clicking on the spot where it should be makes it render again) ! Note that this bug is *not* related with the idleUpdate() issue (it also affects my viewer which doesn't include the new idleUpdate() buggy code). Well, because of your "no", I will put the investigations on these issues on hold and instead waste my time with guess work as to what changes are actually related with the new server baking code or not in the 2Mb diff I got... Great achievement !... > .../... > If you have questions about how the code works, and especially the new > messages exchanged regarding avatar appearance, ask them here and we'll > do what we can to help. I'm smart enough to figure out by myself how those messages work, thank you ! I didn't ask you to explain me how your code works, but *just* to provide me (and all TPV developers alike) with the *actual*, *relevant* changes from the *current* viewer-development branch. So, thank you for *nothing* !... >:-( (A rather pissed off and fed up) Henri. From sldev at free.fr Tue Dec 18 02:41:39 2012 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 18 Dec 2012 11:41:39 +0100 Subject: [opensource-dev] OpenSource reciprocal help (was: Re: Upcoming server side avatar baking) In-Reply-To: References: <50CB9CEA.3000509@lindenlab.com> <20121217094311.051b20aa.sldev@free.fr> <50CF8C43.1060707@lindenlab.com> Message-ID: <20121218114139.9bf39476.sldev@free.fr> On Tue, 18 Dec 2012 05:53:02 +0100, Latif Khalifa wrote: > On Mon, Dec 17, 2012 at 10:18 PM, Oz Linden (Scott Lawrence) > > People who don't fancy themselves to be the infallible gods of system > design often find it beneficial to hear the feedback, especially in > opensource projects. It might even lead to (gasp) more reliable system > and better customer satisfaction. In fact, it was not just feedback: there has been a "feedforward" from me, months ago (see the quoted emails below, exchanged with Oz back in July). > Whenever I relapse into using my time to help improve Linden Lab's > products by doing testing, filing bug reports and repro cases, Oz > Linden's attitude quickly convinces me that it's not worth it. > > (This email started as my feedback about some timing issue with > network messages that could potentially cause bake fails, but then I > saw all-knowing Oz dismiss any need for it) I'd rather not judge "Oz, the man" because it is hard to tell whether his actions are the only result of his own decisions and doings, or are the materialization of LL's policy towards OpenSource and, if we can judge from the resulting actions their policy would clearly be: "take benefit of all the advantages OpenSource can bring to us (i.e. free coding and debugging horsepower provided by volunteering developers), and dismiss all the duties OpenSource cooperation involves in return (such as providing clean diffs for changed we made behind closed doors(*) before releasing them, but also providing an *open* list of known bugs to developers)". As far as I am concerned, while I am very sorry for the poor implementation choice (and while I saw it coming and tried my best to offer a smarter and yet easy alternative), I can live with it (in 35+ years of programming I've seen so many poor implementation choices that I long lost the count and learned to make with them). No, what bothers me most (and what I *can* and *do* judge) is that LL (or Oz, or both), do(es)n't seem to (want to) understand what OpenSource entails (as benefits, rights, but also *duties* !)... Henri. (*) This is one of the worst problems with LL's viewer development: they modify stuff for months behind closed doors instead of doing it in the open... That's *NOT* the OpenSource way of doing things !!! And here is the "feedforward" stuff: --------------------------------------------------------------- Date: Tue, 17 Jul 2012 00:12:26 +0200 From: Henri Beauchamp To: "Oz Linden (Scott Lawrence)" Subject: Upcoming changes to the baking system and "current outfit" folder Greetings, Although I'm not invited to the TPV meetings (not that it would change many things anyway, since those are performed on voice and I won't understand half of what is said as a result), I was made aware that you (LL) are planing to *impose* the use of the "current outfit" folder to implement the future baking system... I personally got many grudges against this "current outfit" folder and the way the v2/3 viewers auto-create and auto-delete assets (be them links for the COF or, for example, auto-re-creating calling cards to mirror the friends list on login): - It is totally useless from the user's point of view (especially with viewers that provide a proper "Worn Items" tab, with full folder/items list of worn items, like Snowglobe did) and it therefore clobbers the inventory for nothing. - It is incompatible with OpenSim grids which don't support inventory links. - It can cause inventory losses in case of asset server and/or sim server issues; typical case: either the asset server got issues or you just logged in/entered in a new RC channel sim, and you change your outfit: the viewer messes up with the COF, deleting and creating assets in it and bang ! your inventory gets corrupted (this is in no way an hypothetical issue: it happened to me once while testing viewer 3 on a RC channel on the main grid, to see if inventory updates were also failing with LL's viewer on this particular RC (which was indeed the case), and I lost my whole #RLV folder, a folder that the "support" team was unable (unwilling ?) to recover (they apparently have no backup or refuse to use them !!!). When things go wrong with asset and/or sim servers, users are told not to mess up with their inventory, but with viewer 2/3, the simple fact of changing an outfit *does* cause automatic items creations/ deletions (and most users will be unaware of that)... This is BAD ! Because of the above issues, the Cool VL Viewer doesn't make use of the current outfit folder (you may even delete that folder altogether to keep your inventory lean and clean). Instead, it uses an XML/LLSD file in the per-account settings directory (meaning there is one such file for each avatar on each grid; they're even two for SL avatars: one for the production grid and one for the beta grid). The XML/LLSD is basically a list of inventory items UUIDs (one map for attachments, one map for wearables, the latter listed in the proper order so they are layered in the correct sequence on re-wear). It works wonders while not having any of the COF inconvenients. I would *really* prefer not to have to implement the COF stuff and I wish to keep my method which I find way more elegant and indisputably more reliable. My guess is that the only use of the current outfit folder in the future baking system will be to provide a list of inventory items UUIDs (and in fact the UUIDs of the wearables only) together with their layer info (in the links descriptions: what a dirty hack this, too !...) so that the server knows what and how to bake them. In this case, LL could provide an alternative method for viewers not implementing the COF: a message could be sent by the viewer (via a capability) that would hold all the said UUIDs in the proper order (i.e. taking the layers into account). Basically, instead of sending a "go for it, COF is populated, bake from it !" message to the server, the viewer would send a "go for it, here is the list of the inventory items UUIDs to bake !". This would be dead easy to implement as a wrapper to what you (LL) are probably already implementing... Thank you in advance for considering this proposal. Regards, Henri. -------------------------------------------------------------- Date: Wed, 18 Jul 2012 02:20:21 +0200 From: Henri Beauchamp To: "Oz Linden (Scott Lawrence)" Subject: Re: Upcoming changes to the baking system and "current outfit" folder On Tue, 17 Jul 2012 12:18:12 -0400, Oz Linden (Scott Lawrence) wrote: > On 2012-07-16 18:12 , Henri Beauchamp wrote: > > > Greetings, > > > > .../... I was made aware that > > you (LL) are planing to *impose* the use of the "current outfit" folder > > to implement the future baking system... > > I was planning to contact you about this one, actually, but as expected > you beat me to it. > > These changes are coming, but are not imminent, so there will be plenty > of time to make any adjustments that you need to make... I'm not worried about the time/delay: I can implement a minimum COF support in just a few hours (testing and debugging included), and since I provide weekly Cool VL Viewer releases, it is unlikely the viewer would get outdated/incompatible... It's just that I *really* don't want to implement a COF (I find this design flawed, glitchy and useless, for the reasons I already developed), especially since it would be very easy for LL to implement a baking request message that would make the COF presence totally optional (see at the end of this email to, for more ideas about it)... > > I personally got many grudges against this "current outfit" folder > > .../... > > > > - It is totally useless from the user's point of view (especially > > with viewers that provide a proper "Worn Items" tab, with full > > folder/items list of worn items, like Snowglobe did) and it > > therefore clobbers the inventory for nothing. > > Whether or not you present the COF as a visible part of the Inventory > display is entirely up to you; if you prefer to hide it, or present it > in some form you think is better separately that's perfectly ok. Oh, rest assured there would at least be one option to hide the COF should I be forced to implement it, but it no less creates useless items in the inventory... > > - It is incompatible with OpenSim grids which don't support > > inventory links. > > Compatibility with OpenSim isn't a design criteria for us That's a very sad trend that has been going on since v2 is out... I think you (LL) are (once more) committing a big mistake... I guess it will be for me one more occasion to say "I told you..." in a few months or years... Fact is that soon, we (TPV developers) will have little choice but to either drop support for a grid type (either SL or OpenSim), or have to maintain two different viewers, which not every developer will have enough time to dedicate for: I personally will not be able to afford releasing up to 8 viewers each week (SL + OpenSim, Linux + Windows, "stable" + "experimental" releases for each). It's already quite an achievement to release up to 4 viewers each week given the little free time I can spend on them (I'm a fast coder, but there are limits to what I can do). What people will do when their preferred viewer stops working in SL is THE question... AFAIK, even now, Phoenix (which has been reusing the backports and code I wrote for the Cool VL Viewer, i.e. inventory links, multiple attachments, alpha and tattoo layers, mesh...) is still the #1 viewer in SL... If you add the Cool VL Viewer, Singularity and their forks, it makes a very large user base (and moreover, a user base made of advanced users who are also the largest contributors and creators in SL). LL should really *think* about it and avoid compatibility breakage as much as possible (and I will admit that so far, things have not been bad on this aspect: "legacy" services are still working in SL for now, and that's a *very* Good Thing: I would *hate* to loose the legacy profiles or searches, for example). > (and there's nothing about this that they could not support if they > chose to). Sure... But like all OpenSource developers, they do this for free and on their free time (which is not unlimited). If LL clearly shows off a will to break compatibility with OpenSim, the developers of the latter could well decide to just take the next, logical step and right out declare OpenSim will require separate viewers. There has been some synergy between SL and OpenSim (though, since the closure of the Snowglobe v1 project, this synergy seems to be history), and I think it was a good thing for all (SL, OpenSim and their users). > > - It can cause inventory losses .../... > > There is nothing about the use of Inventory for this or any other > purpose that is intrinsically unreliable. Granted, at various times > there have been bugs (it is software after all), some of which have had > unfortunate consequences. At present, we think it's sufficiently > reliable when used correctly to support this, and if that turns out not > to be the case then we'll fix it or change our plans, but past bugs are > not a reason to stop using Inventory. And what will happen when the asset servers have glitches (which is very common, especially on peak hours) ?... Avatars will stop baking grid- wide because their COF will be unreadable by the servers or impossible to update by the viewers... Granted, baking also fails now because of asset server issues, but at least, residents who have a cached inventory list and cached textures for what their avatar is wearing can still bake properly. > > My guess is that the only use of the current outfit folder in the > > future baking system will be to provide a list of inventory items > > UUIDs (and in fact the UUIDs of the wearables only) together with their > > layer info (in the links descriptions: what a dirty hack this, too !...) > > so that the server knows what and how to bake them. > > In this case, LL could provide an alternative method for viewers not > > implementing the COF: a message could be sent by the viewer (via a > > capability) that would hold all the said UUIDs in the proper order > > (i.e. taking the layers into account). Basically, instead of sending > > a "go for it, COF is populated, bake from it !" message to the server, > > the viewer would send a "go for it, here is the list of the inventory > > items UUIDs to bake !". > > This would be dead easy to implement as a wrapper to what you (LL) are > > probably already implementing... > > I've forwarded this to the development team for consideration, and will > let you know if they wish to explore it further. In fact, instead of letting the server read directly from the COF on recieval of a "go for it, COF is populated, bake from it !" message from the viewer, the *standard* message for baking could be the one I proposed ("go for it, here is the list of the inventory items UUIDs to bake !"): this would work just as good for COF-based viewers (with just a little more code to add to retrieve the wearables UUIDs), would make the baking system *independent* from the inventory structure (in case it is changed again in the future) and would let the responsibility to the viewer (and its user) for how the inventory is used and how the outfits are organized in it... > In the mean time, you may want to consider what it would take for > you to provide support for COF at least on the backend. It would take me a *lot* of grumbling and cursing against Lindens and their silly hacky ways of implementing simple, straightforward things and making them into ugly pieces of intricate and unreliable code (frankly... did you have a look at how the COF is implemented in v2/3 viewers ?... It's so intricate and convoluted that it's laughable !)... ;-P > .../... > Rest assured that I'll keep you informed on developments; even if it's > not in our directory, Cool VL has more than enough users that I would > rather not break it. Thank you !... And on my side, rest assured I'll keep pestering each time LL takes such steps as the COF-based baking. ;-) Regards, Henri. From nickyperian at yahoo.com Thu Dec 20 00:03:03 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Thu, 20 Dec 2012 00:03:03 -0800 (PST) Subject: [opensource-dev] Fw: Upcoming server side avatar baking In-Reply-To: <1355764684.11254.YahooMailNeo@web126106.mail.ne1.yahoo.com> References: <50CB9CEA.3000509@lindenlab.com> <20121217094311.051b20aa.sldev@free.fr> <1355751306.96429.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121217165405.34406884.sldev@free.fr> <1355764684.11254.YahooMailNeo@web126106.mail.ne1.yahoo.com> Message-ID: <1355990583.96947.YahooMailNeo@web126106.mail.ne1.yahoo.com> I decided to put some walk with my rather cheap talk. Here is a repackaged server side avatar baking?repository.?https://bitbucket.org/NickyP/viewer-development-sunshine-diff/overview It is 2 changesets atop the last point in viewer-development used in sunshine-external. Those 2 can be reduced to 1 by using MQ. I did this to prove I had enough hg foo to do it; not to have continuing maintenance of it. This badly breaks history from sunshine-external and should only be used to as guide for a path forward for v1 viewer developers wanting to implement server-side baking. I have not tried to pull and build to newer viewer code and make no promises. I built windows and logged to aditi SunshineTest sim. ----- Forwarded Message ----- >From: Nicky Perian >To: Henri Beauchamp ; "opensource-dev at lists.secondlife.com" >Sent: Monday, December 17, 2012 11:18 AM >Subject: Re: [opensource-dev] Upcoming server side avatar baking > > >I fail to see how?anyone's?time (LL devs included) is more or less valuable during the upcoming holidays. > > >You can work this through to diff using hg by: > > >clone the sunshine repo. >find the point of first sunshine commit. >update to it >give it a sunshine bookmark or branch. doesn't matter which >update to tip and do a dummy commit (may not be needed) >clone viewer-development >pull the sunshine branch into v-d do not update or merge the branch >hg graft the beginning to end sunshine branch change sets >resolve the merges as you go >once done the sunshine branch will be re-based to the front of v-d >change the phase of all the cs, if not allready, to draft >import all to mq >un-apply all but first >fold all the un-applied to the first? >export a patch/diff. >? >this is more or less the procedure i have used to cherry pick. > > >>________________________________ >> From: Henri Beauchamp >>To: opensource-dev at lists.secondlife.com >>Sent: Monday, December 17, 2012 9:54 AM >>Subject: Re: [opensource-dev] Upcoming server side avatar baking >> >>On Mon, 17 Dec 2012 05:35:06 -0800 (PST), Nicky Perian wrote: >> >>> Henri >>> I was able to merge and build and verify kokua on aditi; the top 2 commits are post merge tweaks. I don't know if that can help diff wise but, feel free to use. >>> The last upstream merge to kokua was viewer-release, last Monday's merge. >>> Nicky >>> https://bitbucket.org/NickyP/kokua-sunshine-external/overview >> >>I'm afraid it doesn't help. What I need to avoid wasting my little >>free time in this period of the year, is a clean diff with only the >>*relevant*, *minimal* changes in it. >> >>The fact you could merge the sunshine branch with another v3-based >>viewer doesn't help (you simply merged stuff that is still not >>validated/adopted/committed to the viewer-development and viewer-beta >>banches together the (soon) mandatory server side baking code). >> >>Regards, >> >>Henri. >>_______________________________________________ >>Policies and (un)subscribe information available here: >>http://wiki.secondlife.com/wiki/OpenSource-Dev >>Please read the policies before posting to keep unmoderated posting privileges >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121220/8a276d07/attachment.htm From sldev at free.fr Thu Dec 20 01:56:44 2012 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 20 Dec 2012 10:56:44 +0100 Subject: [opensource-dev] Fw: Upcoming server side avatar baking In-Reply-To: <1355990583.96947.YahooMailNeo@web126106.mail.ne1.yahoo.com> References: <50CB9CEA.3000509@lindenlab.com> <20121217094311.051b20aa.sldev@free.fr> <1355751306.96429.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121217165405.34406884.sldev@free.fr> <1355764684.11254.YahooMailNeo@web126106.mail.ne1.yahoo.com> <1355990583.96947.YahooMailNeo@web126106.mail.ne1.yahoo.com> Message-ID: <20121220105644.a25d4b03.sldev@free.fr> On Thu, 20 Dec 2012 00:03:03 -0800 (PST), Nicky Perian wrote: > I decided to put some walk with my rather cheap talk. > Here is a repackaged server side avatar baking?repository. >?https://bitbucket.org/NickyP/viewer-development-sunshine-diff/overview I'm afraid it didn't work... The diff I get with viewer-development is still 2Mb big and includes many irrelevant changes such as UI code refactoring, path finding tools changes, etc, etc, etc... No need to waste your time any more, anyway, since I wasted mine yesterday to clean up the 2Mb diff (which is now only 1.4Mb big, i.e. 40% of the changes in sunshine-external are unrelated to the new server-side baking code !). If anyone wants this cleaned-up diff, let me know and I'll send it to you. Regards, Henri. From nickyperian at yahoo.com Thu Dec 20 06:38:02 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Thu, 20 Dec 2012 14:38:02 -0000 Subject: [opensource-dev] Review Request: Sunshine review information only to use the graphical elements of codereview Message-ID: <20121220143802.32103.5266@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/613/ ----------------------------------------------------------- Review request for Viewer. Description ------- Sunshine. Information only. Diffs ----- .hgignore 7b0d9576e16b BuildParams 7b0d9576e16b autobuild.xml 7b0d9576e16b build.sh 7b0d9576e16b debian/changelog PRE-CREATION debian/control PRE-CREATION debian/copyright PRE-CREATION debian/rules PRE-CREATION indra/CMakeLists.txt 7b0d9576e16b indra/cmake/00-Common.cmake 7b0d9576e16b indra/cmake/APR.cmake 7b0d9576e16b indra/cmake/CMakeLists.txt 7b0d9576e16b indra/cmake/CSharpMacros.cmake 7b0d9576e16b indra/cmake/ConfigurePkgConfig.cmake PRE-CREATION indra/cmake/Copy3rdPartyLibs.cmake 7b0d9576e16b indra/cmake/CopyBackToSource.cmake 7b0d9576e16b indra/cmake/DirectX.cmake 7b0d9576e16b indra/cmake/DragDrop.cmake 7b0d9576e16b indra/cmake/Externals.cmake 7b0d9576e16b indra/cmake/FindELFIO.cmake 7b0d9576e16b indra/cmake/FindLLQtWebkit.cmake 7b0d9576e16b indra/cmake/FindMT.cmake 7b0d9576e16b indra/cmake/FindMono.cmake 7b0d9576e16b indra/cmake/FindMySQL.cmake 7b0d9576e16b indra/cmake/FindSVN.cmake 7b0d9576e16b indra/cmake/GLEXT.cmake PRE-CREATION indra/cmake/GLOD.cmake 7b0d9576e16b indra/cmake/GooglePerfTools.cmake 7b0d9576e16b indra/cmake/Havok.cmake 7b0d9576e16b indra/cmake/LLAppearance.cmake PRE-CREATION indra/cmake/LLAppearanceUtility.cmake PRE-CREATION indra/cmake/LLCommon.cmake 7b0d9576e16b indra/cmake/LLDatabase.cmake 7b0d9576e16b indra/cmake/LLRender.cmake 7b0d9576e16b indra/cmake/LLScene.cmake 7b0d9576e16b indra/cmake/LLWindow.cmake 7b0d9576e16b indra/cmake/LLXML.cmake 7b0d9576e16b indra/cmake/LLXUIXML.cmake 7b0d9576e16b indra/cmake/Linking.cmake 7b0d9576e16b indra/cmake/MonoDeps.cmake 7b0d9576e16b indra/cmake/MonoEmbed.cmake 7b0d9576e16b indra/cmake/MySQL.cmake 7b0d9576e16b indra/cmake/OpenGL.cmake 7b0d9576e16b indra/cmake/Prebuilt.cmake 7b0d9576e16b indra/cmake/Python.cmake 7b0d9576e16b indra/cmake/UI.cmake 7b0d9576e16b indra/cmake/Variables.cmake 7b0d9576e16b indra/cmake/VisualLeakDetector.cmake 7b0d9576e16b indra/integration_tests/llimage_libtest/CMakeLists.txt 7b0d9576e16b indra/integration_tests/llui_libtest/CMakeLists.txt 7b0d9576e16b indra/linux_crash_logger/CMakeLists.txt 7b0d9576e16b indra/linux_updater/CMakeLists.txt 7b0d9576e16b indra/linux_updater/linux_updater.cpp 7b0d9576e16b indra/llappearance/CMakeLists.txt PRE-CREATION indra/llappearance/llavatarappearance.h PRE-CREATION indra/llappearance/llavatarappearance.cpp PRE-CREATION indra/llappearance/llavatarappearancedefines.h PRE-CREATION indra/llappearance/llavatarappearancedefines.cpp PRE-CREATION indra/llappearance/llavatarjoint.h PRE-CREATION indra/llappearance/llavatarjoint.cpp PRE-CREATION indra/llappearance/llavatarjointmesh.h PRE-CREATION indra/llappearance/llavatarjointmesh.cpp PRE-CREATION indra/llappearance/lldriverparam.h PRE-CREATION indra/llappearance/lldriverparam.cpp PRE-CREATION indra/llappearance/lljointpickname.h PRE-CREATION indra/llappearance/lllocaltextureobject.h PRE-CREATION indra/llappearance/lllocaltextureobject.cpp PRE-CREATION indra/llappearance/llpolymesh.h PRE-CREATION indra/llappearance/llpolymesh.cpp PRE-CREATION indra/llappearance/llpolymorph.h PRE-CREATION indra/llappearance/llpolymorph.cpp PRE-CREATION indra/llappearance/llpolyskeletaldistortion.h PRE-CREATION indra/llappearance/llpolyskeletaldistortion.cpp PRE-CREATION indra/llappearance/lltexglobalcolor.h PRE-CREATION indra/llappearance/lltexglobalcolor.cpp PRE-CREATION indra/llappearance/lltexlayer.h PRE-CREATION indra/llappearance/lltexlayer.cpp PRE-CREATION indra/llappearance/lltexlayerparams.h PRE-CREATION indra/llappearance/lltexlayerparams.cpp PRE-CREATION indra/llappearance/lltexturemanagerbridge.h PRE-CREATION indra/llappearance/lltexturemanagerbridge.cpp PRE-CREATION indra/llappearance/llviewervisualparam.h PRE-CREATION indra/llappearance/llviewervisualparam.cpp PRE-CREATION indra/llappearance/llwearable.h PRE-CREATION indra/llappearance/llwearable.cpp PRE-CREATION indra/llappearance/llwearabledata.h PRE-CREATION indra/llappearance/llwearabledata.cpp PRE-CREATION indra/llappearance/llwearabletype.h PRE-CREATION indra/llappearance/llwearabletype.cpp PRE-CREATION indra/llaudio/CMakeLists.txt 7b0d9576e16b indra/llcharacter/CMakeLists.txt 7b0d9576e16b indra/llcharacter/llcharacter.h 7b0d9576e16b indra/llcharacter/llcharacter.cpp 7b0d9576e16b indra/llcharacter/lljoint.h 7b0d9576e16b indra/llcharacter/lljoint.cpp 7b0d9576e16b indra/llcharacter/llvisualparam.h 7b0d9576e16b indra/llcharacter/llvisualparam.cpp 7b0d9576e16b indra/llcharacter/tests/lljoint_test.cpp 7b0d9576e16b indra/llcommon/imageids.h 7b0d9576e16b indra/llcommon/imageids.cpp 7b0d9576e16b indra/llcommon/lldictionary.h 7b0d9576e16b indra/llcommon/llfile.h 7b0d9576e16b indra/llcommon/llfile.cpp 7b0d9576e16b indra/llcommon/llsdserialize.cpp 7b0d9576e16b indra/llcommon/llversionserver.h 7b0d9576e16b indra/llcommon/llversionviewer.h 7b0d9576e16b indra/llcommon/tests/bitpack_test.cpp 7b0d9576e16b indra/llcommon/tests/llinstancetracker_test.cpp 7b0d9576e16b indra/llcrashlogger/CMakeLists.txt 7b0d9576e16b indra/llimage/CMakeLists.txt 7b0d9576e16b indra/llimage/llimagetga.cpp 7b0d9576e16b indra/llinventory/CMakeLists.txt 7b0d9576e16b indra/llinventory/llinventory.cpp 7b0d9576e16b indra/llinventory/llinventorytype.h 7b0d9576e16b indra/llinventory/llpermissions.h 7b0d9576e16b indra/llinventory/llpermissions.cpp 7b0d9576e16b indra/llinventory/llsaleinfo.h 7b0d9576e16b indra/llinventory/llsaleinfo.cpp 7b0d9576e16b indra/llkdu/CMakeLists.txt 7b0d9576e16b indra/llmath/CMakeLists.txt 7b0d9576e16b indra/llmath/llvolume.cpp 7b0d9576e16b indra/llmessage/CMakeLists.txt 7b0d9576e16b indra/llmessage/llhttpassetstorage.cpp 7b0d9576e16b indra/llmessage/lliosocket.cpp 7b0d9576e16b indra/llmessage/llregionflags.h 7b0d9576e16b indra/llmessage/llurlrequest.cpp 7b0d9576e16b indra/llmessage/message_prehash.h 7b0d9576e16b indra/llmessage/message_prehash.cpp 7b0d9576e16b indra/llmessage/tests/llhttpclient_test.cpp 7b0d9576e16b indra/llmessage/tests/test_llsdmessage_peer.py 7b0d9576e16b indra/llplugin/CMakeLists.txt 7b0d9576e16b indra/llplugin/slplugin/CMakeLists.txt 7b0d9576e16b indra/llprimitive/CMakeLists.txt 7b0d9576e16b indra/llprimitive/llprimitive.h 7b0d9576e16b indra/llprimitive/llprimitive.cpp 7b0d9576e16b indra/llrender/CMakeLists.txt 7b0d9576e16b indra/llrender/llfontfreetype.cpp 7b0d9576e16b indra/llrender/llfontgl.cpp 7b0d9576e16b indra/llrender/llfontregistry.cpp 7b0d9576e16b indra/llrender/llgl.h 7b0d9576e16b indra/llrender/llgl.cpp 7b0d9576e16b indra/llrender/llglslshader.h 7b0d9576e16b indra/llrender/llgltexture.h PRE-CREATION indra/llrender/llgltexture.cpp PRE-CREATION indra/llrender/llimagegl.h 7b0d9576e16b indra/llrender/llimagegl.cpp 7b0d9576e16b indra/llrender/llrender.cpp 7b0d9576e16b indra/llrender/llrender2dutils.h PRE-CREATION indra/llrender/llrender2dutils.cpp PRE-CREATION indra/llrender/llrendertarget.h 7b0d9576e16b indra/llrender/llrendertarget.cpp 7b0d9576e16b indra/llrender/lltexture.h 7b0d9576e16b indra/llrender/lluiimage.h PRE-CREATION indra/llrender/lluiimage.cpp PRE-CREATION indra/llrender/llvertexbuffer.cpp 7b0d9576e16b indra/llui/CMakeLists.txt 7b0d9576e16b indra/llui/llcombobox.cpp 7b0d9576e16b indra/llui/llconsole.cpp 7b0d9576e16b indra/llui/llfunctorregistry.h 7b0d9576e16b indra/llui/llkeywords.cpp 7b0d9576e16b indra/llui/lllayoutstack.cpp 7b0d9576e16b indra/llui/lllineeditor.cpp 7b0d9576e16b indra/llui/lllocalcliprect.cpp 7b0d9576e16b indra/llui/lltextbase.cpp 7b0d9576e16b indra/llui/lltexteditor.cpp 7b0d9576e16b indra/llui/lltoolbar.cpp 7b0d9576e16b indra/llui/llui.h 7b0d9576e16b indra/llui/llui.cpp 7b0d9576e16b indra/llui/lluiimage.h 7b0d9576e16b indra/llui/lluiimage.cpp 7b0d9576e16b indra/llui/tests/llurlentry_test.cpp 7b0d9576e16b indra/llui/tests/llurlmatch_test.cpp 7b0d9576e16b indra/llvfs/CMakeLists.txt 7b0d9576e16b indra/llvfs/llvfile.cpp 7b0d9576e16b indra/llwindow/CMakeLists.txt 7b0d9576e16b indra/llwindow/GL/glh_extensions.h 7b0d9576e16b indra/llwindow/llwindow.h 7b0d9576e16b indra/llwindow/llwindow.cpp 7b0d9576e16b indra/llwindow/llwindowheadless.h 7b0d9576e16b indra/llwindow/llwindowheadless.cpp 7b0d9576e16b indra/llwindow/llwindowmacosx.h 7b0d9576e16b indra/llwindow/llwindowmacosx.cpp 7b0d9576e16b indra/llwindow/llwindowmesaheadless.h 7b0d9576e16b indra/llwindow/llwindowmesaheadless.cpp 7b0d9576e16b indra/llwindow/llwindowsdl.h 7b0d9576e16b indra/llwindow/llwindowsdl.cpp 7b0d9576e16b indra/llwindow/llwindowwin32.h 7b0d9576e16b indra/llwindow/llwindowwin32.cpp 7b0d9576e16b indra/llxml/CMakeLists.txt 7b0d9576e16b indra/lscript/lscript_compile/CMakeLists.txt 7b0d9576e16b indra/lscript/lscript_compile/bison.bat 7b0d9576e16b indra/lscript/lscript_compile/indra.l 7b0d9576e16b indra/lscript/lscript_execute/CMakeLists.txt 7b0d9576e16b indra/lscript/lscript_execute/lscript_execute.cpp 7b0d9576e16b indra/lscript/lscript_execute/lscript_readlso.cpp 7b0d9576e16b indra/lscript/lscript_library/CMakeLists.txt 7b0d9576e16b indra/mac_crash_logger/CMakeLists.txt 7b0d9576e16b indra/mac_updater/CMakeLists.txt 7b0d9576e16b indra/media_plugins/base/CMakeLists.txt 7b0d9576e16b indra/media_plugins/example/CMakeLists.txt 7b0d9576e16b indra/media_plugins/gstreamer010/CMakeLists.txt 7b0d9576e16b indra/media_plugins/gstreamer010/llmediaimplgstreamervidplug.cpp 7b0d9576e16b indra/media_plugins/quicktime/CMakeLists.txt 7b0d9576e16b indra/media_plugins/webkit/CMakeLists.txt 7b0d9576e16b indra/newview/CMakeLists.txt 7b0d9576e16b indra/newview/English.lproj/InfoPlist.strings 7b0d9576e16b indra/newview/Info-SecondLife.plist 7b0d9576e16b indra/newview/app_settings/settings.xml 7b0d9576e16b indra/newview/character/avatar_lad.xml 7b0d9576e16b indra/newview/linux_tools/wrapper.sh 7b0d9576e16b indra/newview/llagent.h 7b0d9576e16b indra/newview/llagent.cpp 7b0d9576e16b indra/newview/llagentcamera.cpp 7b0d9576e16b indra/newview/llagentwearables.h 7b0d9576e16b indra/newview/llagentwearables.cpp 7b0d9576e16b indra/newview/llagentwearablesfetch.cpp 7b0d9576e16b indra/newview/llappearance.h 7b0d9576e16b indra/newview/llappearancemgr.h 7b0d9576e16b indra/newview/llappearancemgr.cpp 7b0d9576e16b indra/newview/llappviewer.h 7b0d9576e16b indra/newview/llappviewer.cpp 7b0d9576e16b indra/newview/llassetuploadresponders.cpp 7b0d9576e16b indra/newview/llavatariconctrl.cpp 7b0d9576e16b indra/newview/llbuycurrencyhtml.cpp 7b0d9576e16b indra/newview/llcallbacklist.h 7b0d9576e16b indra/newview/llcallbacklist.cpp 7b0d9576e16b indra/newview/llcofwearables.cpp 7b0d9576e16b indra/newview/llcolorswatch.cpp 7b0d9576e16b indra/newview/llcompilequeue.cpp 7b0d9576e16b indra/newview/lldirpicker.cpp 7b0d9576e16b indra/newview/lldrawable.cpp 7b0d9576e16b indra/newview/lldrawpoolbump.cpp 7b0d9576e16b indra/newview/lldrawpoolterrain.cpp 7b0d9576e16b indra/newview/lldrawpoolwater.cpp 7b0d9576e16b indra/newview/lldriverparam.h 7b0d9576e16b indra/newview/lldriverparam.cpp 7b0d9576e16b indra/newview/lldynamictexture.h 7b0d9576e16b indra/newview/lldynamictexture.cpp 7b0d9576e16b indra/newview/llestateinfomodel.h 7b0d9576e16b indra/newview/llestateinfomodel.cpp 7b0d9576e16b indra/newview/llface.cpp 7b0d9576e16b indra/newview/llfasttimerview.cpp 7b0d9576e16b indra/newview/llfavoritesbar.cpp 7b0d9576e16b indra/newview/llfilepicker.cpp 7b0d9576e16b indra/newview/llflexibleobject.cpp 7b0d9576e16b indra/newview/llfloaterauction.cpp 7b0d9576e16b indra/newview/llfloateravatartextures.h 7b0d9576e16b indra/newview/llfloateravatartextures.cpp 7b0d9576e16b indra/newview/llfloaterbuycontents.cpp 7b0d9576e16b indra/newview/llfloaterbuyland.cpp 7b0d9576e16b indra/newview/llfloaterbvhpreview.cpp 7b0d9576e16b indra/newview/llfloatergesture.cpp 7b0d9576e16b indra/newview/llfloatergodtools.h 7b0d9576e16b indra/newview/llfloatergodtools.cpp 7b0d9576e16b indra/newview/llfloaterimagepreview.cpp 7b0d9576e16b indra/newview/llfloaterland.cpp 7b0d9576e16b indra/newview/llfloatermodelpreview.cpp 7b0d9576e16b indra/newview/llfloaterregioninfo.cpp 7b0d9576e16b indra/newview/llfloaterreporter.cpp 7b0d9576e16b indra/newview/llfloaterscriptdebug.cpp 7b0d9576e16b indra/newview/llfloatersidepanelcontainer.h 7b0d9576e16b indra/newview/llfloatersidepanelcontainer.cpp 7b0d9576e16b indra/newview/llfloateruipreview.cpp 7b0d9576e16b indra/newview/llfolderview.cpp 7b0d9576e16b indra/newview/llfriendcard.cpp 7b0d9576e16b indra/newview/llgesturemgr.cpp 7b0d9576e16b indra/newview/llglsandbox.cpp 7b0d9576e16b indra/newview/llgroupiconctrl.cpp 7b0d9576e16b indra/newview/llhudeffectlookat.cpp 7b0d9576e16b indra/newview/llhudtext.cpp 7b0d9576e16b indra/newview/llimview.cpp 7b0d9576e16b indra/newview/llinventorybridge.h 7b0d9576e16b indra/newview/llinventorybridge.cpp 7b0d9576e16b indra/newview/llinventoryicon.h 7b0d9576e16b indra/newview/llinventoryicon.cpp 7b0d9576e16b indra/newview/llinventorylistitem.cpp 7b0d9576e16b indra/newview/llinventorymodel.cpp 7b0d9576e16b indra/newview/llinventorymodelbackgroundfetch.cpp 7b0d9576e16b indra/newview/llinventorypanel.cpp 7b0d9576e16b indra/newview/lllocalbitmaps.h 7b0d9576e16b indra/newview/lllocalbitmaps.cpp 7b0d9576e16b indra/newview/lllocaltextureobject.h 7b0d9576e16b indra/newview/lllocaltextureobject.cpp 7b0d9576e16b indra/newview/lllocationinputctrl.cpp 7b0d9576e16b indra/newview/llmaniprotate.cpp 7b0d9576e16b indra/newview/llmanipscale.cpp 7b0d9576e16b indra/newview/llmaniptranslate.cpp 7b0d9576e16b indra/newview/llmediactrl.cpp 7b0d9576e16b indra/newview/llmeshrepository.cpp 7b0d9576e16b indra/newview/llmorphview.cpp 7b0d9576e16b indra/newview/llnetmap.cpp 7b0d9576e16b indra/newview/llpanelclassified.cpp 7b0d9576e16b indra/newview/llpanelcontents.cpp 7b0d9576e16b indra/newview/llpaneleditwearable.h 7b0d9576e16b indra/newview/llpaneleditwearable.cpp 7b0d9576e16b indra/newview/llpanelface.cpp 7b0d9576e16b indra/newview/llpanelgrouplandmoney.cpp 7b0d9576e16b indra/newview/llpanelgroupnotices.cpp 7b0d9576e16b indra/newview/llpanelland.cpp 7b0d9576e16b indra/newview/llpanellandmarkinfo.cpp 7b0d9576e16b indra/newview/llpanelobject.cpp 7b0d9576e16b indra/newview/llpanelobjectinventory.cpp 7b0d9576e16b indra/newview/llpanelpermissions.cpp 7b0d9576e16b indra/newview/llpanelplaceprofile.cpp 7b0d9576e16b indra/newview/llpaneltopinfobar.cpp 7b0d9576e16b indra/newview/llpanelvolume.cpp 7b0d9576e16b indra/newview/llpanelwearing.cpp 7b0d9576e16b indra/newview/llphysicsmotion.cpp 7b0d9576e16b indra/newview/llpipelinelistener.h PRE-CREATION indra/newview/llpipelinelistener.cpp PRE-CREATION indra/newview/llpolymesh.h 7b0d9576e16b indra/newview/llpolymesh.cpp 7b0d9576e16b indra/newview/llpolymorph.h 7b0d9576e16b indra/newview/llpolymorph.cpp 7b0d9576e16b indra/newview/llpostcard.cpp 7b0d9576e16b indra/newview/llpreviewtexture.cpp 7b0d9576e16b indra/newview/llregioninfomodel.h 7b0d9576e16b indra/newview/llregioninfomodel.cpp 7b0d9576e16b indra/newview/llsaveoutfitcombobtn.cpp 7b0d9576e16b indra/newview/llscreenchannel.cpp 7b0d9576e16b indra/newview/llscrollingpanelparam.cpp 7b0d9576e16b indra/newview/llscrollingpanelparambase.cpp 7b0d9576e16b indra/newview/llsechandler_basic.cpp 7b0d9576e16b indra/newview/llselectmgr.cpp 7b0d9576e16b indra/newview/llsidepanelappearance.h 7b0d9576e16b indra/newview/llsidepanelappearance.cpp 7b0d9576e16b indra/newview/llsidepaneltaskinfo.cpp 7b0d9576e16b indra/newview/llspatialpartition.cpp 7b0d9576e16b indra/newview/llspeakers.cpp 7b0d9576e16b indra/newview/llstartup.cpp 7b0d9576e16b indra/newview/llsurface.cpp 7b0d9576e16b indra/newview/lltexglobalcolor.h 7b0d9576e16b indra/newview/lltexglobalcolor.cpp 7b0d9576e16b indra/newview/lltexlayer.h 7b0d9576e16b indra/newview/lltexlayer.cpp 7b0d9576e16b indra/newview/lltexlayerparams.h 7b0d9576e16b indra/newview/lltexlayerparams.cpp 7b0d9576e16b indra/newview/lltexturectrl.cpp 7b0d9576e16b indra/newview/lltexturefetch.cpp 7b0d9576e16b indra/newview/lltextureview.cpp 7b0d9576e16b indra/newview/lltoastgroupnotifypanel.cpp 7b0d9576e16b indra/newview/lltoastnotifypanel.cpp 7b0d9576e16b indra/newview/lltoolbrush.cpp 7b0d9576e16b indra/newview/lltoolcomp.cpp 7b0d9576e16b indra/newview/lltooldraganddrop.cpp 7b0d9576e16b indra/newview/lltoolfocus.cpp 7b0d9576e16b indra/newview/lltoolmorph.cpp 7b0d9576e16b indra/newview/lltoolpie.cpp 7b0d9576e16b indra/newview/lltoolplacer.cpp 7b0d9576e16b indra/newview/llurlhistory.cpp 7b0d9576e16b indra/newview/llviewerattachmenu.cpp 7b0d9576e16b indra/newview/llviewercamera.cpp 7b0d9576e16b indra/newview/llviewerdisplay.cpp 7b0d9576e16b indra/newview/llviewerinventory.h 7b0d9576e16b indra/newview/llviewerinventory.cpp 7b0d9576e16b indra/newview/llviewerjoint.h 7b0d9576e16b indra/newview/llviewerjoint.cpp 7b0d9576e16b indra/newview/llviewerjointmesh.h 7b0d9576e16b indra/newview/llviewerjointmesh.cpp 7b0d9576e16b indra/newview/llviewermediafocus.cpp 7b0d9576e16b indra/newview/llviewermenu.h 7b0d9576e16b indra/newview/llviewermenu.cpp 7b0d9576e16b indra/newview/llviewermessage.cpp 7b0d9576e16b indra/newview/llviewerobject.h 7b0d9576e16b indra/newview/llviewerobject.cpp 7b0d9576e16b indra/newview/llviewerobjectlist.cpp 7b0d9576e16b indra/newview/llviewerparcelmedia.cpp 7b0d9576e16b indra/newview/llviewerparcelmgr.cpp 7b0d9576e16b indra/newview/llviewerregion.h 7b0d9576e16b indra/newview/llviewerregion.cpp 7b0d9576e16b indra/newview/llviewershadermgr.h 7b0d9576e16b indra/newview/llviewerstats.cpp 7b0d9576e16b indra/newview/llviewertexlayer.h PRE-CREATION indra/newview/llviewertexlayer.cpp PRE-CREATION indra/newview/llviewertexteditor.cpp 7b0d9576e16b indra/newview/llviewertexture.h 7b0d9576e16b indra/newview/llviewertexture.cpp 7b0d9576e16b indra/newview/llviewertexturelist.h 7b0d9576e16b indra/newview/llviewertexturelist.cpp 7b0d9576e16b indra/newview/llviewervisualparam.h 7b0d9576e16b indra/newview/llviewervisualparam.cpp 7b0d9576e16b indra/newview/llviewerwearable.h PRE-CREATION indra/newview/llviewerwearable.cpp PRE-CREATION indra/newview/llviewerwindow.cpp 7b0d9576e16b indra/newview/llvlcomposition.cpp 7b0d9576e16b indra/newview/llvoavatar.h 7b0d9576e16b indra/newview/llvoavatar.cpp 7b0d9576e16b indra/newview/llvoavatardefines.h 7b0d9576e16b indra/newview/llvoavatardefines.cpp 7b0d9576e16b indra/newview/llvoavatarself.h 7b0d9576e16b indra/newview/llvoavatarself.cpp 7b0d9576e16b indra/newview/llvograss.cpp 7b0d9576e16b indra/newview/llvoicevisualizer.cpp 7b0d9576e16b indra/newview/llvoicevivox.cpp 7b0d9576e16b indra/newview/llvosky.cpp 7b0d9576e16b indra/newview/llvosurfacepatch.cpp 7b0d9576e16b indra/newview/llvotree.cpp 7b0d9576e16b indra/newview/llvovolume.cpp 7b0d9576e16b indra/newview/llvowlsky.cpp 7b0d9576e16b indra/newview/llwaterparamset.cpp 7b0d9576e16b indra/newview/llwearable.h 7b0d9576e16b indra/newview/llwearable.cpp 7b0d9576e16b indra/newview/llwearableitemslist.cpp 7b0d9576e16b indra/newview/llwearablelist.h 7b0d9576e16b indra/newview/llwearablelist.cpp 7b0d9576e16b indra/newview/llwearabletype.h 7b0d9576e16b indra/newview/llwearabletype.cpp 7b0d9576e16b indra/newview/llworldmap.h 7b0d9576e16b indra/newview/llworldmap.cpp 7b0d9576e16b indra/newview/llworldmapview.cpp 7b0d9576e16b indra/newview/llworldmipmap.cpp 7b0d9576e16b indra/newview/pipeline.h 7b0d9576e16b indra/newview/pipeline.cpp 7b0d9576e16b indra/newview/res/viewerRes.rc 7b0d9576e16b indra/newview/skins/default/textures/textures.xml 7b0d9576e16b indra/newview/skins/default/xui/en/menu_attachment_other.xml 7b0d9576e16b indra/newview/skins/default/xui/en/menu_attachment_self.xml 7b0d9576e16b indra/newview/skins/default/xui/en/menu_avatar_other.xml 7b0d9576e16b indra/newview/skins/default/xui/en/menu_avatar_self.xml 7b0d9576e16b indra/newview/skins/default/xui/en/menu_inspect_avatar_gear.xml 7b0d9576e16b indra/newview/skins/default/xui/en/menu_inspect_self_gear.xml 7b0d9576e16b indra/newview/tests/llviewertexture_stub.cpp PRE-CREATION indra/newview/tests/llworldmap_test.cpp 7b0d9576e16b indra/newview/tests/llworldmipmap_test.cpp 7b0d9576e16b indra/newview/viewer_manifest.py 7b0d9576e16b indra/test/CMakeLists.txt 7b0d9576e16b indra/test/io.cpp 7b0d9576e16b indra/test/llpermissions_tut.cpp 7b0d9576e16b indra/test/llsaleinfo_tut.cpp 7b0d9576e16b indra/test/llstreamtools_tut.cpp 7b0d9576e16b indra/test/lltemplatemessagebuilder_tut.cpp 7b0d9576e16b indra/test_apps/llplugintest/CMakeLists.txt 7b0d9576e16b indra/viewer_components/login/CMakeLists.txt 7b0d9576e16b indra/viewer_components/updater/CMakeLists.txt 7b0d9576e16b indra/win_crash_logger/CMakeLists.txt 7b0d9576e16b scripts/messages/message_template.msg 7b0d9576e16b scripts/messages/message_template.msg.sha1 7b0d9576e16b Diff: http://codereview.secondlife.com/r/613/diff/ Testing ------- Built and logged to aditi. Thanks, Nicky Perian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121220/7466799d/attachment-0001.htm From chaosstar at gmail.com Thu Dec 20 09:12:04 2012 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 20 Dec 2012 18:12:04 +0100 Subject: [opensource-dev] Fw: Upcoming server side avatar baking In-Reply-To: <20121220105644.a25d4b03.sldev@free.fr> References: <50CB9CEA.3000509@lindenlab.com> <20121217094311.051b20aa.sldev@free.fr> <1355751306.96429.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121217165405.34406884.sldev@free.fr> <1355764684.11254.YahooMailNeo@web126106.mail.ne1.yahoo.com> <1355990583.96947.YahooMailNeo@web126106.mail.ne1.yahoo.com> <20121220105644.a25d4b03.sldev@free.fr> Message-ID: On Thu, Dec 20, 2012 at 10:56 AM, Henri Beauchamp wrote: > On Thu, 20 Dec 2012 00:03:03 -0800 (PST), Nicky Perian wrote: > >> I decided to put some walk with my rather cheap talk. >> Here is a repackaged server side avatar baking repository. >> https://bitbucket.org/NickyP/viewer-development-sunshine-diff/overview > > I'm afraid it didn't work... The diff I get with viewer-development > is still 2Mb big and includes many irrelevant changes such as UI code > refactoring, path finding tools changes, etc, etc, etc... > > No need to waste your time any more, anyway, since I wasted mine > yesterday to clean up the 2Mb diff (which is now only 1.4Mb big, > i.e. 40% of the changes in sunshine-external are unrelated to the > new server-side baking code !). > > If anyone wants this cleaned-up diff, let me know and I'll send it to > you. > > Regards, > > Henri. Why are you folks not doing something like this? 1. hg clone viewer-dev 2. change to the viewer-dev folder 3. 'hg pull https://hg.secondlife.com/sunshine-external' 4. hg merge 5. clean up the 3-way diff of llviewerversion.h 6. hg diff > foo.diff The result is a 356k large foo.diff file that's much easier to clean up than a 2 mb monstrosity. --Chalice Yao From chaosstar at gmail.com Thu Dec 20 09:36:23 2012 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 20 Dec 2012 18:36:23 +0100 Subject: [opensource-dev] Fw: Upcoming server side avatar baking In-Reply-To: References: <50CB9CEA.3000509@lindenlab.com> <20121217094311.051b20aa.sldev@free.fr> <1355751306.96429.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121217165405.34406884.sldev@free.fr> <1355764684.11254.YahooMailNeo@web126106.mail.ne1.yahoo.com> <1355990583.96947.YahooMailNeo@web126106.mail.ne1.yahoo.com> <20121220105644.a25d4b03.sldev@free.fr> Message-ID: A little update, the diff produced through this method sadly does not hold the sunshine changes, but the code that's not in sunshine yet. I thought mercurial would be so smart as to recognize the current repo as the parent which to treat as the thing to diff against, but it seems the steps I used cause the diff to be based off the sunshine either way. The clone method of merging repos indeed creates the 2.2MB file. --Chalice Yao On Thu, Dec 20, 2012 at 6:12 PM, Ambrosia wrote: > On Thu, Dec 20, 2012 at 10:56 AM, Henri Beauchamp wrote: >> On Thu, 20 Dec 2012 00:03:03 -0800 (PST), Nicky Perian wrote: >> >>> I decided to put some walk with my rather cheap talk. >>> Here is a repackaged server side avatar baking repository. >>> https://bitbucket.org/NickyP/viewer-development-sunshine-diff/overview >> >> I'm afraid it didn't work... The diff I get with viewer-development >> is still 2Mb big and includes many irrelevant changes such as UI code >> refactoring, path finding tools changes, etc, etc, etc... >> >> No need to waste your time any more, anyway, since I wasted mine >> yesterday to clean up the 2Mb diff (which is now only 1.4Mb big, >> i.e. 40% of the changes in sunshine-external are unrelated to the >> new server-side baking code !). >> >> If anyone wants this cleaned-up diff, let me know and I'll send it to >> you. >> >> Regards, >> >> Henri. > > Why are you folks not doing something like this? > > 1. hg clone viewer-dev > 2. change to the viewer-dev folder > 3. 'hg pull https://hg.secondlife.com/sunshine-external' > 4. hg merge > 5. clean up the 3-way diff of llviewerversion.h > 6. hg diff > foo.diff > > The result is a 356k large foo.diff file that's much easier to clean > up than a 2 mb monstrosity. > > > --Chalice Yao From nickyperian at yahoo.com Thu Dec 20 11:31:03 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Thu, 20 Dec 2012 11:31:03 -0800 (PST) Subject: [opensource-dev] Fw: Upcoming server side avatar baking In-Reply-To: References: <50CB9CEA.3000509@lindenlab.com> <20121217094311.051b20aa.sldev@free.fr> <1355751306.96429.YahooMailNeo@web126103.mail.ne1.yahoo.com> <20121217165405.34406884.sldev@free.fr> <1355764684.11254.YahooMailNeo@web126106.mail.ne1.yahoo.com> <1355990583.96947.YahooMailNeo@web126106.mail.ne1.yahoo.com> <20121220105644.a25d4b03.sldev@free.fr> Message-ID: <1356031863.89827.YahooMailNeo@web126104.mail.ne1.yahoo.com> The ?difference in the re-base method of 1.9+ vs 2.2 most likely due to not having merge changsets in play. I think a rebase and not folding the changesets might be better. Then, if there are ui and pathfinding changesets not needed in v1 they could be stripped leaving only server bake changsets. Mixed purpose changesets would have to be edited for for server side code and committed. ?This of course would not build but, that doesn't seem to be the purpose any way. ? >________________________________ > From: Ambrosia >To: Henri Beauchamp >Cc: opensource-dev at lists.secondlife.com >Sent: Thursday, December 20, 2012 11:36 AM >Subject: Re: [opensource-dev] Fw: Upcoming server side avatar baking > >A little update, > >the diff produced through this method sadly does not hold the sunshine changes, >but the code that's not in sunshine yet. > >I thought mercurial would be so smart as to recognize the current repo >as the parent >which to treat as the thing to diff against, but it seems the steps I >used cause the diff >to be based off the sunshine either way. > >The clone method of merging repos indeed creates the 2.2MB file. > >--Chalice Yao > >On Thu, Dec 20, 2012 at 6:12 PM, Ambrosia wrote: >> On Thu, Dec 20, 2012 at 10:56 AM, Henri Beauchamp wrote: >>> On Thu, 20 Dec 2012 00:03:03 -0800 (PST), Nicky Perian wrote: >>> >>>> I decided to put some walk with my rather cheap talk. >>>> Here is a repackaged server side avatar baking repository. >>>> https://bitbucket.org/NickyP/viewer-development-sunshine-diff/overview >>> >>> I'm afraid it didn't work... The diff I get with viewer-development >>> is still 2Mb big and includes many irrelevant changes such as UI code >>> refactoring, path finding tools changes, etc, etc, etc... >>> >>> No need to waste your time any more, anyway, since I wasted mine >>> yesterday to clean up the 2Mb diff (which is now only 1.4Mb big, >>> i.e. 40% of the changes in sunshine-external are unrelated to the >>> new server-side baking code !). >>> >>> If anyone wants this cleaned-up diff, let me know and I'll send it to >>> you. >>> >>> Regards, >>> >>> Henri. >> >> Why are you folks not doing something like this? >> >> 1. hg clone viewer-dev >> 2. change to the viewer-dev folder >> 3. 'hg pull https://hg.secondlife.com/sunshine-external' >> 4. hg merge >> 5. clean up the 3-way diff of llviewerversion.h >> 6. hg diff > foo.diff >> >> The result is a 356k large foo.diff file that's much easier to clean >> up than a 2 mb monstrosity. >> >> >> --Chalice Yao >_______________________________________________ >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/20121220/05b226fc/attachment.htm From jessica.lyon at phoenixviewer.com Mon Dec 24 15:14:57 2012 From: jessica.lyon at phoenixviewer.com (Jessica Lyon) Date: Mon, 24 Dec 2012 18:14:57 -0500 Subject: [opensource-dev] Merry Christmas! Message-ID: On behalf of everyone here at the Phoenix Firestorm Project we would like to wish the entire open source community and everyone at Linden Lab to have a wonderful Christmas and safe, relaxing, happy holidays! Ha!... as if open source devs actually take holidays... Happy Holidays to LL anyways! ;-) -- Jessica Lyon Phoenix Firestorm Project Inc http://phoenixviewer.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121224/e7a33068/attachment.htm From nickyperian at yahoo.com Sun Dec 30 12:29:02 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Sun, 30 Dec 2012 12:29:02 -0800 (PST) Subject: [opensource-dev] sunshine-external colladadom boost filesystem3 undefines Linux64 Message-ID: <1356899342.80390.YahooMailNeo@web126106.mail.ne1.yahoo.com> I am building a linux 64 bit kokua merge of sunshine-external. I have a link issue with colladadom looking for boost filesystem3 functions. The viewer is built with boost 1.52 and colladadom boost 1.48. This is not different than the LL source/build environment. Linux 32 builds with just a few tweaks but, using mostly LL prebuilt libraries.? Boost 1.52 dropped filesystem2 and filesystem3 and just builds as filesystem without the 2/3 source code split and dropped the deprecated directive. /home/nicky/kokua-sunshine-external/build-linux-x86_64/packages/lib/release/libcollada14dom.so: undefined reference to `boost::filesystem3::detail::status(boost::filesystem3::path const&, boost::system::error_code*)' /home/nicky/kokua-sunshine-external/build-linux-x86_64/packages/lib/release/libcollada14dom.so: undefined reference to `boost::filesystem3::path::parent_path() const' /home/nicky/kokua-sunshine-external/build-linux-x86_64/packages/lib/release/libcollada14dom.so: undefined reference to `boost::filesystem3::detail::create_directories(boost::filesystem3::path const&, boost::system::error_code*)' /home/nicky/kokua-sunshine-external/build-linux-x86_64/packages/lib/release/libcollada14dom.so: undefined reference to `boost::filesystem3::detail::rename(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::system::error_code*)' /home/nicky/kokua-sunshine-external/build-linux-x86_64/packages/lib/release/libcollada14dom.so: undefined reference to `boost::filesystem3::detail::create_directory(boost::filesystem3::path const&, boost::system::error_code*)' /home/nicky/kokua-sunshine-external/build-linux-x86_64/packages/lib/release/libcollada14dom.so: undefined reference to `boost::filesystem3::detail::remove_all(boost::filesystem3::path const&, boost::system::error_code*)' /home/nicky/kokua-sunshine-external/build-linux-x86_64/packages/lib/release/libcollada14dom.so: undefined reference to `boost::filesystem3::detail::remove(boost::filesystem3::path const&, boost::system::error_code*)' collect2: ld returned 1 exit status make[2]: *** [newview/kokua-bin] Error 1 make[1]: *** [newview/CMakeFiles/kokua-bin.dir/all] Error 2 make: *** [all] Error 2 ERROR: building default configuration returned 2 For more information: try re-running your command with --verbose or --debug I have tried rebuilding colladadom using boost 1.52. That corrects the filesystem undefines but, then there is a problem libxml2 undefines. Anyone have suggestions?? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121230/49e2957b/attachment.htm