{
  'Build Id': 'unset',
  'Business Unit': ['Platform'],
  'Date of First Response': '2021-06-16T17:22:36.945-0500',
  'How would you like the feature to work?': 'Re-Request of:\r\nhttps://jira.secondlife.com/browse/VWR-23322\r\n\r\nOriginal request has been awaiting review for eleven years. (October 2010)\r\n\r\nOverview\r\n\r\nIn 2007 when Windlight and Nimble technologies were acquired by Linden Lab. The company responsible for those technologies, WindwardMark Interactive (http://www.windwardmark.net) lists both the acquisition of those technologies by SecondLife as well as an overview of the capabilities of those technologies as were acquired. When we look at the Windwardmark features list for Windlight, we see a number of things that were implemented in SecondLife with the technology (including the 3D Cloud system that is Nimble), but curiously we have yet to see one of the prominent features of Windlight included.\r\n\r\nWindwardmark Interactive Official Site Listing for Windlight\r\nhttp://www.windwardmark.net/products.php?page=windlight&sub=technology&subsub=1\r\n\r\nWeather:\r\n"WindLight can significantly enhance particle-based weather systems, and includes a sample dynamic weather framework. The scene can instantly shift from a bright autumn day to intense storm conditions, with adjustable particle density, direction, and flow. Rain, snow, sleet, and blinding dust storms- both natural and manmade- are all rendered correctly by WindLight."\r\n\r\nIt would stand to reason that with the acquisition of Windlight and Nimble technologies from Windwardmark Interactive, that the functionality for Weather and Global Atmosphere Settings are built into the framework natively, but not implemented by Linden Lab for whatever reason they may have stated in 2007 after their initial tests.\r\n\r\nIf I were to guess, I\'d say their reasoning was undue stress on the servers for rendering and streaming these effects to the user, however this reasoning is flawed as such effects would not be required to render server side at all. \r\n\r\nHowever, the purpose of the Dynamic Weather Framework for Windlight would be to implement those effects not server-side but instead locally via Screen Space (Camera Viewport), which would then put the burden of the graphical ability on each individual using SecondLife and not the server systems, making the server strain argument a moot point. The purpose of server-side rendering and calculation is for critical items by which many users may scrutinize (object location, physics, etc) but it is highly unlikely that any two or more persons in the environment will ever find a need to scrutinize raindrops from the sky. Therefore, this graphical effect is better suited to render to the camera viewport (screen space), eliminating lag and stress on the servers.\r\n\r\nGlobal Atmosphere Settings\r\n[Already Accomplished through EEP]\r\n\r\nUser Created Zones\r\nA related issue to the implementation of the Dynamic Weather framework of Windlight is that without zones, it would rain/snow/storm inside of buildings. I can imagine this was a concern when the system was originally tested, and later used as another reason why Linden Lab would not implement Weather natively. However, again, the inclusion of user created zones would solve this problem and render it a moot point.\r\n\r\n"Zones are 3-dimensional areas in the scene. Within a zone the normal environmental world rules can be changed. The world itself can be thought of as one or two large zones. The primary zone is the main part of the world above the world water level. If water is enabled, the area below the water level can be thought of as another zone. However, what if you want an area below the water level that is not flooded with water, such as a doomed city or submarine? Or what if you want water that is not part of the world\'s "ocean", such as a swimming pool? This is where zones are useful.\r\n\r\nUsing zones, you can define areas that have different gravity, water, or fog settings, as well as change some of the sounds used within."\r\n\r\nThis is a quote from another system that already has this solved. Under water should be treated as a zone and as such the ability to "swim" should be native to the viewer. Likewise, the concept of defining zones is inherent to game design as a basic staple. In a sandbox system such as Second Life, allowing the participants to define Zones via special permissions on a prim, whereby the containing space of said prim would be the defined zone whereby those rules are in effect, would be the ideal route.\r\n\r\nIn the context of Second Life, Zone creation should require a Group Specified permission as it is a specialized prim whereby the laws of gravity, lighting, VoIP Exclusivity, and yes even Particles can be limited or expanded. The usage of Zones is also something to consider when creating an in ground swimming pool, for instance, whereby one of the faces is declared to be Linden Water and act as such, while the inside of the zone acts as modified gravity (buoyancy) and automatically trigger the swimming animation and movement archetype. Zones are also useful for limiting chat range to inside of itself, as well as setting an entry list. They are also needed in order to properly implement the Windlight Weather system that Linden research already has at their disposal (block particles) so weather can be told not to extend into buildings or other areas.\r\n\r\nIncluded with this Feature Request are snapshots from Windwardmark Interactive demonstrating that the Windlight system indeed has a Dynamic Weather Framework natively, and such options are normally located on the Clouds tab of the Atmosphere settings.\r\n\r\nI am also including the link to a Youtube video of Windlight showing the Dynamic Weather Framework in action:\r\n\r\nhttp://www.youtube.com/watch?v=BULIwsz_WCM&feature=player_embedded#!\r\n\r\nEpilogue (Why I\'m Not Letting This Die)\r\n\r\nThis has been a long standing JIRA request since 2007, one which I have voted on and added the same materials here in order to better illustrate the intentions. Interestingly, after writing about this publicly, and linking to the specific JIRA, the feature request seems to no longer be found on the JIRA, and the actual Press Release listed on Windwardmark Interactive (pointing to Linden Lab for the press release) shows a Page Not Found.\r\n\r\nSince the original JIRA request seems to have disappeared (Permission Violation on the original JIRA link: http://jira.secondlife.com/browse/VWR-6632), and a sudden rash of selective amnesia about it permeates, I\'m making this resubmission in hopes that it will be taken serious this time around and no longer ignored for years. I agree that this is a complex thing to implement, but you\'d be surprised to know that a majority of the components are already in place to make it happen.\r\n\r\nStep One: Weather is integrated from Windlight. That portion is already hiding out in the Windlight acquisition somewhere.\r\n\r\nStep Two: A builder creates Zones by creating Primitives and checking off the box that designates it as a Zone (invisible, changes environment). Then uses those to set whether the zone allows particles originating outside to enter or escape from inside, you could set different lighting in there, assign a sound, etc. But the up shot here would be that you\'ve used a native Primitives system (that people don\'t really use much anymore) and breathed new usage and life into it. \r\n\r\nTherefore when an agent enters said zone the screen space particle of weather would not exist within that zone but it would continue outside of it. Can also double for spatial lighting, limiting sounds, etc. But in this case we\'re talking about just applying it to allow areas to be zoned out to know where weather can occur and where it is occluded.',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'With the new EEP system in place, one of the biggest issues has been implementing low-lag weather on a sim. We can do this today with mesh based systems that spread across a sim with multiple objects, but the performance hit and Land Impact (plus camera interference) isn\'t ideal. \r\n\r\nInstead, implementing the native screen space particle solution for weather that originally came with Windlight (as it would still pertain to EEP) is a better solution. Doubly so if one would write a script that can call an API from a weather service and have that control the weather setting for a sim in an organic manner. \r\n\r\nWith this, obviously comes the need for particle occlusion and that\'s where Zones come in - a solution that dates back to the early 2000s when such was implemented in ActiveWorlds successfully. Except that AW had to create a prims system to use for Zones whereas SL already has prims by default to use as a "Primitive Type" to define the zone areas.\r\n\r\nI\'ve been predominantly baffled since 2007 that this hasn\'t been natively integrated into Second Life yet and it\'s now 2021 with the original still awaiting review (and forgotten).',
}