Native Weather in #SecondLife with Zones @Rodvik
I’ve probably said this before, so please bare with me. Windlight as used in SecondLife has the native ability to include Weather built in. Why it was never really implemented has been sort of a mystery to me since 2007, but I’ve been told by @onikenkon on twitter that the reasoning behind not implementing the native weather system in Windlight happens to be along the lines that the Linden Lab programmers didn’t seem to know how to stop it from raining inside buildings.
SecondLife JIRA Report
Integrate Windlight Weather
https://jira.secondlife.com/browse/VWR-23322
If you would like to see Weather natively enabled in SecondLife, I urge that you visit the JIRA page and click on “Watch” – I also invite discussion and comments on the matter.
This blog post is a companion to that JIRA in order to explain in further detail how the User Created Zones requirement would work in conjunction with Windlight Weather in order to block rain inside buildings (among many other things it would allow).
I have to say that this is quite a bizarre claim for a team of programmers whose sole purpose in life at Linden Lab is to program a video game engine. In the gaming industry this should automatically have been answered with “Implement Zones”, which in and of itself should be on the list of things one would be expected to know about when dealing with 3D game engines. Why the hell do I, a presumably under qualified dolt who can’t grace the doors of Linden Lab, know this is a solution yet the apparently overqualified rockstars who grace the name Linden leave a fundamental component in 3D game engines out of the release since its inception? It can’t possibly be that ridiculous to implement if a place like ActiveWorlds managed to code it from the ground up because they didn’t have the luxury of prims to start with.
@Rodvik, if you’re reading this (though I doubt it) I highly suggest Linden Lab tosses in the measly remainder of the donation to get Qarl to work on Parametric Deformation for Mesh as an independent contractor, and to save grace with the community. This is clearly very important to the community and should not be ignored. Matter of fact, look… stop the book tours and public appearances or whatever it is you’re doing and hold a meeting in your ranks at Linden Lab. You need to teach those programmers the difference between priority and not a priority. If you’re the one sabotaging their idea of priority with arbitrary milestones or whatever, you need to chill out and really see what you have on the table. Seriously, you’re dropping the ball and I really don’t want you to. As far as zones are concerned, you come from EA, a flipping video game company. Even you know that Zones are a staple of video games to offer design control over many aspects of a 3D environment.
But I digress…
If anything, upon hearing these sorts of things in the ranks of Linden Lab, I would have either docked somebody’s pay or seriously reconsidered whether the programmers were truly qualified to be working on that project at all.
I understand I’m quite cynical about this, but something so basic a premise as user defined zones, which are a given staple of game programming, should not be a mystery to a well paid team of rockstars at Linden Lab. I mean, this is one of those things where literally years worth of important or half-assed priorities at Linden Lab have consistently superseded a basic fundamental inclusion of a game engine. It’s such a fundamental inclusion that the mere lack of it forbids Linden Lab from properly utilizing what must have been a multi-million dollar technology purchase (WindLight).
In ActiveWorlds, the ability to define user created zones has been a staple since at least 2005 and entails essentially the following premise: http://wiki.activeworlds.com/index.php?title=Zone
In terms of SecondLife, this should actually be easier to implement than the work required to implement it in ActiveWorlds, in that ActiveWorlds is primarily a “Mesh” based virtual environment and has no concept of “Prims” as in SecondLife. In this manner, ActiveWorlds had to essentially code prims from the ground up simply for use as Zone definition spaces, whereas SecondLife already has prims as the native building system.
So what does a user defined zone really mean?
Well, in respect to SecondLife, you as the user would see another tab on the build menu for Zone, whereby enabling that Prim as a Zone (a checkbox) would turn it into a special primitive with the zone qualities contained within it. The prim would also be natively phantom and normally invisible unless you add the option to “Show Special Objects” to the build menu, much like there is an option to show invisible items. There would be the option to make the zone prim visible as well, in the case the builder is working with a lot of zones and needs them visible while building.
Here is the window for Zones in ActiveWorlds, where you can see all of the options available to the builder:
As you can see, there are numerous options available when creating zones in a virtual environment. For people who didn’t jump to the wiki link provided for zones at ActiveWorlds, that information will be found below (with some comments pertaining to SecondLife). From here on, it gets pretty technical and wordy without much in the way of pictures, so bare with me:
Tag Name
Assigning a tag name to a zone allows the user to trigger events for entering and exiting the zone.
// This would essentially be the Description field or Prim Name in SecondLife
Volume Shape
This controls the shape of the area. There are 3 types:
- Cube - The zone is a rectangular area in size as defined by the Size values.
- Cylinder - The zone is a cylindrical area. The X Size defines the radius of the cylinder, the Y Size defines the height, and the Z Size is unused.
- Sphere - The zone is a sphere whose radius is defined by the X Size value. The Y and Z values are not used.
//This is pretty much not needed in SecondLife because we already have Prims
Priority
Priority defines the most important zone when two zones intersect. A higher priority number means the zone will have more importance over other zones with lower priority numbers.
For example, on the diagram on the right there are two shapes. On the top, the red square has a priority of 1 while the blue circle has a priority of 0. Therefore, the red square becomes becomes more important than the blue circle. On the bottom, the blue circle's priority is changed to 2, higher than red square's priority of 1. Therefore, it has become more important than the red square.
A useful example for priorities are for large weather zones, where a large zone dims the lighting in a pale blue haze for ice. However, this zone may intersect a building, where it will also affect the interior. A zone with normal lighting can be placed in the building with a priority of 1 while the ice zone has a priority of 0. Therefore, the building's zone will cancel out the pale blue haze inside the building.
Zone Properties Dialog Box
Size
This defines the size of the zone. See "Volume Shape" above for details on how these values are used.
Gravity
This controls how fast users will fall when in this zone. A value of 1.00 is "normal" gravity.
Friction
This controls how fast users will stop when walking in this zone. A value of 1.00 is considered "normal" friction. Lower values will make walking "slippery", while higher values will slow walking speed and cause the user to stop more quickly.
Water
If checked, the zone is filled with water (or whatever liquid) and a user will swim when they are inside of the zone. Note that a zone is invisible, so users will not see the surface of the water. You will need to add an object to the scene if you want to make the water surface visible.
//In terms of SecondLife, adding the top face of the zone to use the water shader as the oceans do would be a bonus.
Block Particles
If checked, this zone will be included by particles when checking for collision.
//Essentially this is how it doesn’t rain inside buildings in ActiveWorlds unless you forget to create a zone for your building or structure. The same would apply to SecondLife and Windlight Weather.
Block Lights
If checked, lights created with the light command will not be visible if they are outside of this zone.
// SL: Essentially any item outside the zone that has Light enabled will not have any effect on the lighting inside the zone.
Block World Light
If checked, the world light ("sunlight") will not be visible from within this zone. This is useful for making underground or dark areas where the world light source should not be visible.
Block Audio
Any audio that was started by action commands using the sound or media command is muted or faded, if the trigger object lies outside the zone, while the avtar is inside the zone.
Audio played within the zone can only be heard while the avatar is inside the zone and will get muted or faded as soon the avatar is outside the zone.
Audio played by the media command is faded in and out when entering or leaving the zone.
Audio played with the sound command is faded in and stops without been faded, cause of the underlying principle for the sound command only playing the nearest sound at a time.
When a noise command is triggered outside the zone while the avatar is inside a zone, the noise will not be heard. When a noise is triggered right before the avatar enters the zone, the noise will be heard also when the avatar is inside the zone, the noise won't stop playing until the trigger has finished. A noise command triggered inside the zone will not be heard outside the zone.
Ambient sound set in the world feature settings is not affected by this option. To mute global ambient sounds use the Ambient sound field with the zone settings.
//Anything outside of a zone that is playing sound/gestures/etc will not be heard inside the zone. Any sound/gestures/etc inside the zone will only be heard by users inside the zone. This would include Shared Media and Video
Block Chat
If checked, users within this zone will not see the chat of users outside of the zone. Note1: Zones do not block Public Speak either direction across the zone barrier. Note2: Zones do not prevent non-Global bots from hearing across the zone barrier.
//Private spaces for open chat without having to go to group chat internally. Essentially a zone with Block Chat enabled will use its own chat channel transparently for all people inside the zone. Very nice for nightclubs on a sim where you don’t want the text chat, gestures etc to bleed over to the neighbors.
Block Join/Invite
If checked, users within this zone cannot have other users join them and cannot invite anyone.
//SL: Can be extended to allow only certain Group members to invite others via teleport
Color
This controls the color of the fog in this zone, and the color of the water (if applicable).
//SL: This would control a native Windlight Setting within that zone.
Fog Range
This controls the near / far fog settings.
//SL: Another Windlight setting control within the zone
Ambient Sound
This sound (if specified) will repeat in the background when the camera (usually the avatar's head) is in this zone.
//SL: Only a single sound, or chain of sounds for ambient within the zone. As of this post, the equivalent would be a multitude of ambient sound spheres placed across the area to achieve the same effect. Enabling Ambient Sound in a zone would not harm the ambient sound sphere market, but lessen the need for multitudes of them.
Footstep sound
This sound is used if the avatar's feet are in this zone while walking or running.
//SL: Native sound for running or walking on various materials like sand, wood, metal, etc as defined by the space of that zone.
Camera Tag
This specifies that name of a particular camera object within the scene. When the user enters this zone, their camera will switch to the camera matching the given name, and will return to the previous setting when they leave.
//SL: Zoning a furniture set, for instance, would allow the designer to specify a forward facing camera override when sitting on the furniture – where the user could still adjust the camera as they please after that switch. How many times have you sat on a couch next to a wall in a house only to have your camera fly outside the building? Allowing content creators to attach zones to their creations will give them better control and lessen the wild camera positions.
Target Cursor
This specifies the texture that will be used as the center cursor in Move Mode (mouselook).
//SL: Possibly custom target cursors for shooting games?
Voip Enabled
Enable/Disable Voip Rights within a given zone.
//SL: Already an option as a Parcel or Sim owner, this would allow fine tuning of where VoIP is enabled in an area on a zone by zone basis instead of an all or nothing scenario.
Voip Rights
Specify a list of users who will have the rights to participate in Voip conversation within the zone.
//SL: Not restricting VoIP entirely, but giving only certain people within that zone the ability to use VoIP. Business scenarios where there is a single speaker.
In the scope of SecondLife, a Zone is simply a specialized Prim in wireframe which defines an area with special properties. When we talk about whether or not it’s raining inside of a building, we should also ask if that building is within a user created zone with Block Particles enabled, as we would ask in ActiveWorlds.
Defining zones is a staple of video game programming and quite common. To hear that there is a possibility that the programmers at Linden Lab did not know how to stop it from raining inside of buildings puzzles me.
While I admit the implementation of user defined zones would be a complex project within Linden Lab (I’m humoring you, Linden Lab, because ActiveWorlds did it from scratch with a single programmer in 2005), I must also insist that the very lack of this ability is subsequently limiting and/or crippling the technology and what is available to it – namely Windlight which was acquired in 2007 and still has yet to see full implementation.
My Moment of Rage
Waiting since 2007 for a fundamental component pisses me off
Honestly, and I truly mean this – I swear to all that is holy and good in this world, if a Linden shows up on this post and tries to sling a ration of bullshit at me in a comment to excuse themselves for why this hasn’t been properly addressed as a priority, there will be hell. Any manager worth their salt, let alone the CEO of the company, would agree in the face of such negligence to the product and community which it serves. Whether this is addressing user created zones (which instantly negates a large amount of JIRA requests through facilitation) or whether it’s the Parametric Deformation.
That level of absurdity in dismissing things is unacceptable – fundamental flaws and defects in the system should not be ignored for multiple years, and they should not be in a position where your own community walks off and raises the funds to do a job that the company itself should have been doing.
As far as user Created Zones (which would immediately allow Weather to be enabled) I’m pointing to ActiveWorlds, a virtual environment company that doesn’t even register on the grand scheme of competition any more, implementing user created zones from absolute scratch via a single programmer in another country that they have on contract – and they managed to do it in 2005. You cannot possibly tell me that an outdated, underfunded, technology with a single programmer is more adept than the entire team of programmers at Linden Lab.
I refuse to acknowledge that because it’s absolute bull. Just like saying Parametric Deformation is not a priority when it fixes a fundamental flaw with Mesh, which is the entire focus of why Viewer 3 was created.
I mean, is this really what it takes to have the major issues be addressed? Is priority assigned by how much negative publicity it’s drawing for not addressing it? Or you have to be some digerati and Linden kiss-ass for them to acknowledge you?
Geez… No wonder everybody uses Third Party Viewers. At least they are on top of things and really engaging with the community on this stuff. I apologize, but the more I think of this arrogant and dismissive behavior on the part of Linden Lab, the more it pisses me off. Waiting for years to even have a basic component in a game engine acknowledged in an official capacity and implemented is simply asinine.
I mean, the only reason I can see that the ATI 4500/5100 bug ( the one where Viewer 3 is entirely unusable) was looked at and addressed was because Tonya Souther (Firestorm) called out Linden Lab in a public interview. C’mon… seriously? That’s what it takes to light a fire under their asses?
This has got to change. It’s unacceptable.
I’d probably lose my sanity if I were ever a Linden.
No comments:
Post a Comment