Global Atmosphere Settings
Related JIRA: http://jira.secondlife.com/browse/VWR-7677
With Windlight in 2007 came a number of atmospheric effects such as water, sky and lighting which allows us to change the look and feel of the sims we are in if we feel so compelled. From brilliant sunsets, to an eerie fog and overcast day, the atmosphere settings allow us to truly set the mood of an area and create a better immersive environment. However, since the inclusion of windlight settings in 2007, there has not been the obvious inclusion of Global Atmospheric Settings along with it.
Would it not make sense to allow the sim owners and parcel owners to set the atmospheric settings for global use? Imagine going to a sim and the skies are darkened with overcast clouds, or a brilliant shade of pink. The water would be tweaked as per the sim owner as well, allowing for countless water possibilities with the atmosphere to create just the right look and feel.
What does it take to actually do global atmospheric settings? I'm assuming those settings are in an XML file, and as such it would only require that the global settings are saved as a server asset for the sim (just like all the other settings in estate and Land management) and thus would be downloaded as an asset to be applied by the user automatically (unless they are manually overriding the settings locally). The transition from one global preset to another should be set on a slow fader in order to go from one transition to another smoothly (and not suddenly switching).
Weather Effects
Associated JIRA: http://jira.secondlife.com/browse/VWR-6632
Windwardmark Interactive: http://www.windwardmark.net/
Again, with the inclusion of Windlight in 2007, Linden Lab has acquired a very powerful atmospheric system for their viewer, but seem to have ignored one of the major components of the Windlight system: Weather.
The Windlight system includes built in weather effects such as rain, snow, and more but by some fluke of logic in 2007 they were never enabled in SecondLife. Instead we are left with third party solutions which essentially require a ton of particles in 3D space and are not nearly as good looking or effective as would be the native solution such as found in Windlight. The reason the native solution looks better and runs much faster than an in-world solution with particles, is because the Windlight system runs the weather effects natively and attached to the user camera viewport, versus particles in the 3D space.
Video Courtesy of Windwardmark Interactive (makers of Windlight)
The weather effects for Windlight are actually quite impressive, considering they use the local viewport to render the effects quickly. I believe that using Windlight Weather effects would not require processing time on the server, as the effects can be run locally at full speed. It's not as though each individual raindrop needs to be able to be scrutinized by each person, so locally running the effects via camera screen space should suffice. Of course, weather would also be an option in the the Global Atmosphere Settings for the sim owner (and land management).
An excellent place to begin in order to figure out why weather was not implemented when Linden Lab acquired Windlight would be to understand that there is a missing essential in SecondLife (yet another spare part) which would effectively make enabling weather natively not feasible.
User Created Zones
"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.
Using zones, you can define areas that have different gravity, water, or fog settings, as well as change some of the sounds used within."
This 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.
In 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.
Defining zones for buildings and structures which would normally impede or block weather actually take about 30 seconds when the ability to do so exists in the building interface. It's simply telling it that particles outside of that zone do not enter that zone.
And that, is how to implement the already built in weather system of Windlight while ensuring it does not rain, snow, etc inside of buildings. Restricting via Parceling would be a bad idea because the parcels extend upwards into the sky, and would not look natural as you would see columns of no weather extending into the sky (and not in shorter limits of a zone space)
Linden Water Should Invoke Swimming Natively
Coming from the topic of Zones, most game engines define two zones immediately much like you can only have 6 lights in view at any given moment (and two of those lights are the Sun and Moon by default). The two zones which get automatically defined are usually the Above Water zone of the sim space and Below Water zone in sim space and are defaults. Above water, your avatar acts normally unless acted upon by another zone or force, and below water your avatar automatically swims unless acted on by another zone or force.
I find it odd that this basic foundation of programming a 3D environment was neglected since day one and continues to be neglected to this day. When I jump into the ocean, I should automatically swim - not walk along the bottom of the ocean like I have concrete shoes on.
While there are third party solutions available such as Scuba HUDs and swimming wearables which do this for you, it only goes to show that the community is making up for lack of basic functionality in the viewer, and presumably doing so with the ease that should have been present in actually incorporating that functionality natively in the viewer.
Particle Effects Natively in Build Window Options
Of course you can script particle effects in SecondLife, and there are now a number of HUDs you can purchase which give you some basic particle making abilities with a point and click interface, but a Tab on the Build Window natively allowing a user to have a prim generate particles would have been a no-brainer. This is one of the options that I actually miss from Activeworlds in that the Particle system is tied to the building window with a tab and GUI options to modify the settings of the particles you are generating, including ability to specify an image asset to use for the particle itself and glow.
When I first entered SecondLife a few years ago, I was baffled that particles weren't a native option on the build window, and that I either had to script them from scratch, buy a script and modify it, or purchase a separate HUD to use a function that was native to the SecondLife system.
This is one of those spare parts that have been sitting in the box for years (and probably since day one) collecting dust, forgotten. I think it's time to take the part out of the box, dust it off, and put it to use properly.
Enable Dynamic Reflection
Related Web Address: http://secondslog.blogspot.com/2007/01/first-look-into-mirror.html
Way back in the first look viewer when water reflection was enabled (2007), Linden Lab also temporarily enabled Reflection by itself, allowing prims to act as mirrors. At the time, this was huge news and was shown off quite a bit by users in SecondLife via videos online. However, something happened where the normal reflectivity option was removed prior to the release and the only thing we were left with was the water reflections. In effect, the mirrors were disabled before release, and seems to have been relegated to the spare parts box, forgotten.
In the world of Viewer 2 series where Dynamic Lighting and Shadows are being worked on, I feel it is wiser to go back and enable Dynamic Reflections before we continue forward. The reflectivity option would simply use the existing shader that is used for the water reflections, and the Graphics Settings would read "Reflections" instead of "Water Reflections".
I see no reason why mirrors should be disabled and forgotten in SecondLife, since it is clearly not a lag concern if we can already enable water reflections and choose "Everything" on the graphics setting. It has been about three years or longer since reflective surfaces were introduced and then subsequently removed before release, so I would believe at this point that whatever limitations there were to implementing it at the time (three years ago) should be easily overcome today in the year 2010. Below is a video from 2008 showing the use of the water reflections as a mirror (by turning the structure 90 degrees).
Video Courtesy of Adeon Writer in SL
Native Translation of Text
I'm fairly certain something similar exists for Emerald users, but I'd like to take it a step further and suggest browser language be used as the Google Translate API Language pairing, but instead of showing the original text, simply show the translation in text chat to the user's native language so all text is in their native language (whenever it's possible to detect the language properly and translate). Again, there are lots of third party HUDs which translate chat for you, but this is a feature which should be native to the viewer.
RTF Formatting of Notecards
In a world of Web 2.0 and text editing on the web, you would think that it would be possible to have a rich text formatting ability in our notecards by now. I'm writing this blog entry on blogger, and even the interface for blogger is more advanced than SecondLife notecard editing (which is really just sad).
I have the ability to choose a font, text size, bold, italic, text color, web link, text justification, bullet point options, text quote formatting, spell checking, as well as picture and video embed into the document. Don't you think it's about time that we should be able to use rich text formatting in our notecards as well?
Sailing the Null Space Oceans
When you look out into the vast seas of SecondLife, you often get a yearning to sail a ship. Unfortunately this is only possible in Linden protected waters, but really should extend to the null space oceans that extend outward in all directions from sims. Avatar tracking would be done by nearest sim or a central server which simply hands off connections to the users so that users in vicinity of each other connect via a multicast P2P and update each other as to movement, actions and VoIP proximity. In the null space ocean, it wouldn't be possible to build so a majority of those authorizations would be a moot point. Items left in the null space ocean would be set to autoreturn in a set amount of time by default if not being interacted with. This would essentially make it feasible to sail a ship or vehicle out into the infinite oceans without requiring costly servers to handle regions for them.
Allow Multicasting P2P
If there are hundreds of people in an area, it is safe to say that their local cache's are very similar. This is redundant data, and should be shared among peers in order to lessen the load on the main asset servers. Cascading Multicast information would allow the servers to lighten their load by instructing viewers to cascade redundant information to their peers (such as movement) and would remove the burden from the main servers greatly when attempting to process the simultaneous users in bulk. Aside from actions that require authorization such as building, there is quite a lot of information that can skip the main server and simply cascade to nearby peers in a multicast fashion. In the long run, this limited decentralization would allow for many more people to be in a single area without server issues.
Epilogue
Over the course of time, SecondLife as a system has left quite a number of useful additions aside, and forgotten them in their haphazard rush forward. Looking over the things which were forgotten in the past, as well as very obvious things today, it is safe to say that part of the disappointment with SecondLife isn't what it is unable to do, but instead what the viewer is able to do but has been relegated to the spare parts box in the corner to collect dust and remain forgotten.
Can you think of anything else that should be on this list? Go ahead and leave them in the comments.
No comments:
Post a Comment